Date: Sat, 23 May 1998 13:13:00 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Mike Smith <mike@smith.net.au> Cc: Doug Rabson <dfr@nlsystems.com>, current@FreeBSD.ORG Subject: Re: FreeBSD/alpha kernel status report Message-ID: <19980523131300.46017@hydrogen.nike.efn.org> In-Reply-To: <199805231553.IAA00882@antipodes.cdrom.com>; from Mike Smith on Sat, May 23, 1998 at 08:53:51AM -0700 References: <Pine.BSF.3.95q.980523121937.15699E-100000@herring.nlsystems.com> <199805231553.IAA00882@antipodes.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith scribbled this message on May 23: > > Mike Smith took on my hack and was intending to spruce it up a bit to make > > a more generally useful standalone library and probably add ELF kernel > > loading. > > Yup. I've been trying to work out how to separate the libkern bits > from the kernel and make a completely standalone "libsa". The design > of the NetBSD code is pretty clean, so writing a machine-specific > backend will be fairly trivial in most cases. sounds good... > > > for what I would like to do with FreeBSD for bus/device support will > > > require the ability to have the boot loader support loading multiple > > > modules before the kernel starts running... and once this happens, we > > > can essecially eliminate main from the kernel, and simply have it use > > > the module loading code to initalize the kernel... > > > > 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... 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... 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... -- John-Mark Gurney Modem Rev/FAX: +1 541 346 9237 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD Don't trust anyone you don't have the source for 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?19980523131300.46017>