Date: Tue, 10 Feb 1998 10:26:55 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: boot floppy banner Message-ID: <199802101026.DAA25351@usr05.primenet.com> In-Reply-To: <199802100931.BAA00698@dingo.cdrom.com> from "Mike Smith" at Feb 10, 98 01:31:56 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802101026.DAA25351>