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

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

On Wednesday 04 September 2002 01:18 pm, Michael Lauzon wrote:
> Kelledin,
>
> Even though some of what you say is already laid out for us,
> why not contact some of the other distros and see how they do
> it, in that way we could use some of their ideas in doing our
> kernel.

Done quite a bit of that already. ;)

Slackware uses different precompiled kernels for each possible=20
hard-drive controller.

SuSE, Debian, and RedHat use something similar to the initrd=20
system I've proposed.

To get a grasp of the advantages of an initrd, it helps to go=20
over several scenarios:

1) User Joe starts installing Slackware.  Looking through the=20
   bootdisk images, he settles on the plain-jane bare.i disk.  He=20
   goes through the install and installs network and PCMCIA=20
   module packages.  He boots up, and all modules load=20
   properly--but he doesn't have any power management...

   User Joe is rather annoyed.

2) Take scenario 1, but have Joe decide to use the bare+APM=20
   bootdisk instead.  He boots up, but his PCMCIA modules won't=20
   load--they get "unresolved symbol" errors.  This is where the=20
   Slackware method fails.  Your average Slackware user can
   handle this just fine by recompiling the kernel, but User
   Joe might be out in the cold.  Mention "compile your kernel,"
   and a lot of average computer users (like our hero User Joe)
   will cringe in fear/confusion/bewilderment.

3) Hardware manufacturer FastRAID Inc. decides to release Linux=20
   drivers for their RAID controllers.  They first release the=20
   drivers as a patch against the kernel source.  This doesn't do=20
   current distros much good, because a new kernel must be=20
   compiled and booted before an installation script can even=20
   mount the root FS on systems with a FastRAID product.  This is=20
   generally impractical and often completely impossible.

   FastRAID Inc. has a few options at this point:

    a) Release a precompiled "driver pack" for distros which
       support the "driver pack" convention.  FastRAID Inc.=20
       developers must know how to compile a kernel and=20
       familiarize themselves with "driver pack" formats.  The=20
       first is already taken care of (else they wouldn't be able=20
       to release a kernel patch).  The second is probably not=20
       too complicated, assuming there's sufficient=20
       documentation from the distro developers.

       User Joe (who probably wouldn't be recompiling his kernel=20
       anyways) finds that FastRAID products "just work" in his
       Linux distro, and he's happy with that.  User LinuxGod=20
       takes it a step further by getting FastRAID's kernel patch=20
       and compiling a custom kernel himself, at which point he=20
       probably knows how to manage an initrd, or at least knows
       how to dispense with one completely.  Anyone who can't=20
       handle this arrangement probably shouldn't be using Linux=20
       anyways.

    b) Create customized bootdisk images for Slackware (and=20
       similar distros).  This is a bit more daunting for=20
       FastRAID Inc.'s developers.  On top of that, FastRAID Inc.=20
       suddenly has to deal with Scenario 2 type problems, with=20
       User Joe calling their support lines and saying, "Your=20
       bootdisk image breaks my PCMCIA drivers.  You suck.  Or=20
       Slackware sucks.  Or life sucks.  Or something..."

       It wouldn't matter that the solution is just a kernel
       compile away, because User Joe is a bit intimidated about=20
       compiling his own kernel.  In his opinion, this driver=20
       doohickie should "just work", and it's not.  Suddenly he=20
       assumes his distro sucks, Linux as a whole sucks, or=20
       FastRAID Inc. sucks.  In any case, he's not happy.

       At this point, FastRAID Inc. would probably be tempted to=20
       just shrug and say, "Slackware users, you lose."

    c) Just send the patch off to the kernel hackers and let them
       handle it.  While FastRAID Inc. should do this anyways, it=20
       leaves some lag time between releasing the hardware, and=20
       getting it fully supported in Linux.

4) Take User Joe again, but assume he was unfortunate enough to=20
   buy a Packard Bell box without knowing what hard drive=20
   controller is in it.  He doesn't really know which boot=20
   drivers he needs, so he gets stuck with one of two options:

    a) Download lots of Slackware bootdisks and try each of them
       in turn, until he finds one that boots.  This is tedious
       and rather annoying, as he must reboot between every test
       and perhaps have a lot of floppies on hand for the myriad
       separate bootdisks.  Besides which, once he finds a disk
       that works, he could be stuck in Scenario 2 again.

    b) Download a distro with a Redhat-style initrd, and let the
       distro's install script go through a set of driver packs,
       testing each one to see if modprobe loads it without a
       hitch.  Not all hardware will work with this simple=20
       autodetect scheme (ISA hardware especially will be=20
       troublesome), but it might make User Joe's job a lot=20
       easier.  At the very least, he probably won't have to
       reboot between each test.

5) A security/stability/sanity advisory is released for the=20
   current kernel, and a new version is released.  User LinuxGod=20
   takes it in stride; he's good with this.  User Joe...well, we=20
   don't know where User Joe is at this point.  Neither approach=20
   to boot-time drivers can really pull this off perfectly,=20
   because ABI compatibility in the Linux kernel is not=20
   guaranteed for kernel-space code.

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