But if somebody really _wants_ to be sneaky, the boot loader certaily
_could_ try to muck around with x86 segments this way..
What I would suggest people do, if they really want to pursue this, is
to take a look at the way the Mach boot loader works; it's since been
adopted by the BSD folks. Basically, the boot loader switches to 32 bit
mode very early on, before it loads the kernel. In order to do I/O,
there are C subroutines which switches back to real mode, calls the BIOS
routines, and then switches back to protected mode. In the case of
block transfer routines, I believe they use a bounce buffer technique.
The advantage of this is that you can make the boot loader much more
sophisticated, since it can now be written in C. Since it's running in
32 bit mode, it also eliminates the kernel sizing problem. It would
also be possible to write a boot loader which could open a filesystem
and boot any arbitrary file; this eliminates the need to rerun
/sbin/lilo each time you install a kernel.
I suspect we would still use LILO to load the second stage boot loader,
since it would be big enough that it would be easist way to load it.
Once we had this architecture in place, there are all sorts of
interesting things we could do. For example, it would also be possible
to replace the second stage boot loader with one that played bootp and
tftp games in order to net-boot a kernel. We do something like this at
Project Athena, so we that we can arm our cluster patrol people with a
single floppy disk which they can use to insert into a workstation which
needs to be reloaded, and that's all that's needed. When you're using a
very small staff to maintain well over a thousand workstations of many
different architectures, eliminating that second disk when doing a
re-install from scratch is very important.
As an example, it's possible for us to completely reinstall the
OS and Project Athena software on a Decstation 5000/25 in under 25
minutes, using this technique of tftp-booting an install kernel (which
was huge, since included an embedded mini-root filesystem on it, which
was enough to NFS (or AFS) mount a full set of software). Best of all,
once the install procedure is initiated, it could be run unattended; so
our cluster patrol people could eject the boot disk, and wander off to
do their next task.
I'm not suggesting that we actually do this for Linux --- it would be
great, but there would be a lot of work involved. Something like this
is generated needed only in specialized circumstances, such as the one
were you're maintianing a *large* number of cluster workstations with a
small staff. I point it out merely to show some of the things we could
do once we had this architecture in place.
- Ted