[Maxlinux-devel] [RFC] precompiled kernels, initrd, and driver disks

[Kelledin <kel...@sk...>]

Sooner or later, we need to decide how to manage precompiled=20
kernels and precompiled drivers.  So far, the basics of doing=20
this are laid out for us already; we will have almost all=20
drivers compiled as modules, and we will place modules needed at=20
boot-time in an initial RAMdisk image (initrd).  The initial=20
RAMdisk image will contain drivers and applications necessary=20
for loading those drivers and mounting the "real" root FS.

So far, here's what I'm thinking of doing within the initrd:

1) Have a statically compiled binary installed as /sbin/init on=20
   the initrd.  Also have /sbin/modprobe on the initrd as well=20
   (also statically compiled).

2) The initrd's /sbin/init will be responsible for the following:

   - Looking in /etc/modules.rc to determine what modules to=20
     load.

   - Calling /sbin/modprobe to load those modules.

   - Looking in /etc/mount.rc to determine what device to mount=20
     as the "real" root FS, what FS type is on that device, and
     what options to use when mounting it.  "/bin/mount" will
     not be included in the initrd; the initrd's /sbin/init will
     call the mount() syscall directly instead to save space.

   - Mounting the specified device and calling pivot_root() to
     change to the new root FS.

   - Executing the "real" /sbin/init to take over booting.

3) During future versions of the installation program, we should=20
   have a precompiled kernel available, as well as modular=20
   drivers for various driver and filesystem types.  These=20
   modular drivers should be avaliable as compressed packages
   on a separate "driver disk" during install.  The installation
   program should include options for auto-probing drivers,
   configuring which drivers get auto-probed, and specifying
   custom modprobe options for each driver.  There should also
   be a specified format for supplemental driver disks provided
   by third parties (such as hardware manufacturers).

The part we need to decide on together is the format of a=20
compressed "driver pack".  The driver pack should include kernel=20
modules to be loaded, a list of those modules and human-readable=20
one-line comments for each one, and a human-readable one-line=20
description of the driver pack and what it supports.  An=20
optional comprehensive README for the driver should be supported=20
as well.  I have other features in mind, but they can wait.

--=20
Kelledin
"If a server crashes in a server farm and no one pings it, does=20
it still cost four figures to fix?"