Date: Wed, 15 May 1996 10:00:12 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: wpaul@skynet.ctr.columbia.edu, msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.ORG Subject: Re: Making a three-stage boot Message-ID: <199605151700.KAA14829@phaeton.artisoft.com> In-Reply-To: <199605150105.KAA24644@genesis.atrad.adelaide.edu.au> from "Michael Smith" at May 15, 96 10:35:34 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605151700.KAA14829>