From owner-freebsd-current Sat May 23 13:13:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA25627 for freebsd-current-outgoing; Sat, 23 May 1998 13:13:11 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from d183-205.uoregon.edu (d183-205.uoregon.edu [128.223.183.205]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA25609 for ; Sat, 23 May 1998 13:13:08 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by d183-205.uoregon.edu (8.8.8/8.8.7) id NAA21594; Sat, 23 May 1998 13:13:01 -0700 (PDT) Message-ID: <19980523131300.46017@hydrogen.nike.efn.org> Date: Sat, 23 May 1998 13:13:00 -0700 From: John-Mark Gurney To: Mike Smith Cc: Doug Rabson , current@FreeBSD.ORG Subject: Re: FreeBSD/alpha kernel status report References: <199805231553.IAA00882@antipodes.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199805231553.IAA00882@antipodes.cdrom.com>; from Mike Smith on Sat, May 23, 1998 at 08:53:51AM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.6-STABLE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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