From owner-freebsd-hackers Tue Feb 10 02:27:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA26516 for hackers-outgoing; Tue, 10 Feb 1998 02:27:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA26511 for ; Tue, 10 Feb 1998 02:27:01 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id DAA01746; Tue, 10 Feb 1998 03:27:01 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd001737; Tue Feb 10 03:26:57 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id DAA25351; Tue, 10 Feb 1998 03:26:55 -0700 (MST) From: Terry Lambert Message-Id: <199802101026.DAA25351@usr05.primenet.com> Subject: Re: boot floppy banner To: mike@smith.net.au (Mike Smith) Date: Tue, 10 Feb 1998 10:26:55 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <199802100931.BAA00698@dingo.cdrom.com> from "Mike Smith" at Feb 10, 98 01:31:56 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Which things do they complexify, and how? I'm not really attached to > > > the way that the current "extras" stuff works; if there is a more > > > ELF-friendly way to do it, then I'm all ears. > > > > Mostly "knowing where it's safe to load a second stage ELF-based a.out > > booter below 1M". > > How does this complexify the extras loading? The "extras" rock up as > more ELF segments, which the a.out booter can ignore. If we have ELF > as a reality for 3.0, I'll abandon any formal attempt to get the > "extras" stuff into the a.out kernel. The patches can remain for > people that want/need them, but I don't see them having any real > utility. Well, they are already in the a,out kernel, right? Where do they get loaded so that I won't step on them? > Of course, once you have written this a.out loader, you will have been > sucked into writing the third-stage bootstrap I've been whining about > for ages. Then the "extras" loading moves there anyway, size stops > being an issue, and you can handle both kernel types. Well, not really. I technically wouldn't have to write a third stage for an ELF kernel, at least for it to work. > > One very real problem is that we need to start thinking in terms of > > running the initial kernel code (a second stage boot at a minimum) > > in real mode, and making it the kernel's responsibility to go to > > protected mode. > > I'm still not entirely convinced of this. Certainly we need more code > in real mode, but whether that should be the third-stage boot or kernel > startup I'm not sure. Either one works, but the problem is that if there is only a third stage booter for a.out and not for ELF (the initially simplest picture), then if the kernel goes protected, it saves a lot of work on a third stage ELF loader to get a minimal implementation. > > Have you looked at the GRUB code? It claims to have FreeBSD patches > > available, though I'm sure they are quite dated. It makes the same request > > for the kernel to do its own transition to protected mode. > > I looked at it a while back; building it was an atrocious pain and I > was somewhat put off by the blocklisting that it used and the > unfriendly syntax of the CLI. I've investigated a few other > bootloaders, but ultimately the one I keep coming back to is the > NetBSD-i386 standalone loader. > > If you want to make a serious stab at a new bootloader for FreeBSD, > *this* is the one you want. It's a really nice piece of work, but > removing it from the NetBSD kernel to allow it to be built on its own > is something akin to ripping the living heart out of a rhinoceros > using a dental probe. Heh. "This won't hurt... ...there". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe hackers" in the body of the message