From: Rusty Russell <rusty@rustcorp.com.au>
Date: Tue, 6 May 2008 04:42:12 +1000

quoted text
> BTW, I'm fascinated and a little nausiated that you ignore initrds.  We've 
> moved half the kernel brains to userspace with udev, initrd and modules; it's 
> really unfair that you're not sharing all that why-won't-my-machine-boot 
> love.

It's pretty straightforward, if you ask me.  I avoid initrd's like
the plague too.

Building and compressing the initrd would increase my build+reboot
cycle time by at least 40%.

Add to that it's simply an enormous pain in the ass.

And for what?  I know what freakin' drivers to build statically into
my kernel.  I use raw partitions and don't use LVM, I know what
the heck my root filesystem device is named, etc.

The only thing I get "punished" for, where I am absolutely forced to
use an initrd, is when I use qlogic SCSI for the root partition, for
the firmware which we really should have kept in the tree :(

And this is not even a "licensing" issue, like it or not in-kernel
drivers are tied to specific firmware versions both from an API and
from a testing perspective.  Externalizing this is really a nightmare.

And I'm not avoiding udev by doing this.  udev works just fine if I
raw boot a kernel with all the static devices I need to get root
mounted.  All my networking etc. is modular and udev does the right
thing.

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/