From owner-freebsd-hackers Wed May 15 10:04:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA04563 for hackers-outgoing; Wed, 15 May 1996 10:04:26 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA04543 for ; Wed, 15 May 1996 10:04:19 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA14829; Wed, 15 May 1996 10:00:12 -0700 From: Terry Lambert Message-Id: <199605151700.KAA14829@phaeton.artisoft.com> Subject: Re: Making a three-stage boot To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 15 May 1996 10:00:12 -0700 (MST) Cc: wpaul@skynet.ctr.columbia.edu, msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199605150105.KAA24644@genesis.atrad.adelaide.edu.au> from "Michael Smith" at May 15, 96 10:35:34 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > userconfig(), kzip and the 'which kernel' selection are all obvious > candidates. We'll talk about boot-time linking the kernel some other day; > you could use it to do the boot-time driver probe/load stuff that > Terry and I were musing about a while back. Some of this wants ELF module agregation, and some of it wants VM86() BIOS-using fallback drivers in the kernel. Both of these really obviate the need for a "stage three" in the boot process. ELF agregation allows you to load any ELF code segment at any address, and since ELF allows multiple code segments, this means that you can massage a binary file as long as you have a mechanism for identifying load address for things like boot FS driver and boot device driver. Specifically, I could have a kernel with no FS installed that loads a default FS for boot-install in a discardable ELF segment, and loads the actual FS to be used on the disk (like ext2fs) dunamically using the discardable loader. Then when it writes the kernl out on the installed disk, it writes out an ELF segment for the chosen FS driver and patches a static vector segment for where the FS driver is to be loaded. Basically, it builds a static kernel with a default FS type from mudular components, and doesn't need to recompile to get there. This would allow replacement of a Linux kernel (or an SCO kernel, etc.) with a BSD kernel with no other changes to the system. Obviously, ELF "autoinit" segments, where all ELF segments with the proper identifier have an initialization entry point called in order based on component class would be necessary. The dogwork in that area is already done with the init)_main.c code and the KERNINIT interface code. Before agregation is supported, it would be easiest to support a "fallback driver" scenario: default drivers that will work on any hardware in a given driver class, which may be discarded for a hardware-specific (and thus higher performance) driver from the same class. For instance, a disk driver that uses INT 13 calls via VM86() will work with any disk controller that does POST initialization of the INT 13 BIOS vector. That is... any disk capable of booting DOS would be capable of booting BSD. Obviously, for non-PC hardware, the BIOS/VM86()-based fallbacks would be replaced with PPCBug based fallbacks, or, more ideally, OpenFirmware/OpenBoot-based fallbacks. > No, PIC is Position Independent Code. ie. it doesn't give a damn where > it is. You'd have to provide it with a suitable stack and bss perhaps, > depending on whether we outlawed uninitialised globals. (Not sure if you > can do that with gcc). Right. PIC is to allow load address independence. The only interface is known memory regions and preinitialized stack contents when the next set of code is invoked. If you think of the ELF segments as having been PIC'ed, it means that you can agregate them without caring about agregation order. This means that you could agregate ("ELF-link") an FS driver based on multiple segment identifiers in an ELF segment to get a minimal FS interface with shared code with the real FS interface for use by a second stage boot block. This lets you change root FS types as often as you want without paying a premium in terms of having to rework huge amounts of code (which is what's being suggested by a third stage boot). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.