Date: Sat, 23 May 1998 20:56:34 -0700 From: Mike Smith <mike@smith.net.au> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Mike Smith <mike@smith.net.au>, Doug Rabson <dfr@nlsystems.com>, current@FreeBSD.ORG Subject: Re: FreeBSD/alpha kernel status report Message-ID: <199805240356.UAA03957@antipodes.cdrom.com> In-Reply-To: Your message of "Sat, 23 May 1998 13:13:00 PDT." <19980523131300.46017@hydrogen.nike.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Now I never thought of loading more than just the kernel from the > > > bootloader. Its a very good idea given that we (nearly) have a flexible > > > three stage loader. My original intention was to link the modules > > > critical devices (console, system bus, root disk) statically with the > > > kernel and load all the others during autoconfig as the system probes for > > > devices. > > > > Given that the bootstrap loader must already have access to the root > > device (remember that it may be a non-local filesystem), it makes sense > > to use that to construct a kernel similarly endowed, if that's possible. > > > > There's a lot of design missing here though - we would be better off > > starting with your planned arrangement, and adding boot-phase linking > > later, simply because that's closer to what we can achieve right now. > > actually, supporting boot-phase linking isn't hard... what we do is > pass to the first module (that is required to contain the code that > does module loading, or we could pass the buck if we don't support it) > a structure that contains the address/lengths of all the modules that > the boot-loader loaded... then the linker code will link the modules > with itself... Sure, but you have to work out which modules you need to load beforehand, which means having a set of probes that work in the context of the bootloader. This context is machine-dependant, so you lose portability unless the probe is entirely data-driven. We don't have anything like that yet for many busses, so you would require user input or lots more code in some cases (particulary ISA systems). > we probably would want to support loading multiple modules at once so > that we can get better ordering of SYSINITs, but it wouldn't be hard > just to load each module, one at a time... we would have to be careful > to make sure that we support static malloc data areas for all the malloc > types... because some of this code will run before the vm/malloc code > gets initalized, and trying to make sure we avoid malloc until we are > able to use it isn't going to be really possible... Actually, the kernel arena can be set up pretty early on. I certainly think that it's a prerequisite for module binding. > we might run into, out of static memory, but this can be fixed by either > increasing it, or simply making the vm/malloc code link sooner... I'm still inclined to think that you're supporting my argument that we should crawl before we walk. 8) -- \\ 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 freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805240356.UAA03957>