From owner-freebsd-current Sat May 23 11:28:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA18859 for freebsd-current-outgoing; Sat, 23 May 1998 11:23:46 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles231.castles.com [208.214.165.231]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA18812 for ; Sat, 23 May 1998 11:23:41 -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 IAA00882; Sat, 23 May 1998 08:53:51 -0700 (PDT) Message-Id: <199805231553.IAA00882@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Doug Rabson cc: John-Mark Gurney , current@FreeBSD.ORG Subject: Re: FreeBSD/alpha kernel status report In-reply-to: Your message of "Sat, 23 May 1998 12:32:42 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 May 1998 08:53:51 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. > > 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. -- \\ 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