Date: Tue, 10 Feb 1998 11:56:38 -0800 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: mike@smith.net.au (Mike Smith), hackers@FreeBSD.ORG Subject: Re: boot floppy banner Message-ID: <199802101956.LAA02378@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 10 Feb 1998 10:26:55 GMT." <199802101026.DAA25351@usr05.primenet.com>
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? I'm not sure what you mean by "already in the kernel". The code's not committed, no. If you mean "where are they loaded", they're tacked on after the data segment, before the symbol table. There's another member in the bootinfo struct that's set to point to them if they're there, and the end of the kernel (first free page) is adjusted to avoid them. In the kzip case, they're actually loaded after the kzipped kernel image, then relocated to after the kernel itself at startup. Kzipped kernel's can't have extra symbol data, so that works OK. > > 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. If you didn't, I think someone else would. > > 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. I think you'd find that the effort of adding the ELF loader to the third stage would be less than the effort required to run the kernel startup in real mode. YMMV, I am just conjecturing here. > > 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". That sounds like an undertaking. My advice; either rewrite their Makefiles or port the NetBSD make first. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199802101956.LAA02378>