From owner-freebsd-current Sat May 23 22:00:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA09368 for freebsd-current-outgoing; Sat, 23 May 1998 22:00:50 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles167.castles.com [208.214.165.167]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA09363 for ; Sat, 23 May 1998 22:00:47 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id UAA03957; Sat, 23 May 1998 20:56:35 -0700 (PDT) Message-Id: <199805240356.UAA03957@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: John-Mark Gurney cc: Mike Smith , Doug Rabson , current@FreeBSD.ORG Subject: Re: FreeBSD/alpha kernel status report In-reply-to: Your message of "Sat, 23 May 1998 13:13:00 PDT." <19980523131300.46017@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 May 1998 20:56:34 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 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