[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ata and scsi modules in initrd

On Sun, 2007-12-02 at 21:01 -0500, Warren Togami wrote:
> dragoran wrote:
> > [..]
> >> I didn't say we should have all modules in the initrd. But having the
> >> most common would IMHO a good thing.
> > 
> > +1 for having all pata/sata drivers in the initrd by default.
> > 
> Has anyone checked how much larger this would make a typical initrd image?
> The experimental bash-branch of mkinitrd has a simple for loop to load 
> all available kernel modules matching available PCI devices, so we could 
> possibly load the drivers dynamically.  

Code in the initramfs shouldn't have to be modified just because you
throw extra kernel modules in. Seriously. The initramfs isn't hard, it's
a solved problem [0], it goes like this

 - figure out UUID or LABEL [1] for rootfs. Write out an udev rule that
   will create a /dev/root symlink to said device

 - include other udev rules such as /etc/udev/rules.d/80-drivers.rules
   This will automagically load kernel modules in the initramfs if they
   are there. And only the modules that match the hardware will be

 - Do the equivalent of /sbin/start_udev (notably this one can be
   replaced by a three line shell script or so. That's what the upstream
   udev maintainer says anyway)

 - Once /sbin/start_udev is done, see if you have a /dev/root symlink;
   if not, drop to a shell. If you do, mount rootfs, delete yourself and
   exec /sbin/init on the real rootfs

If you're saying that our current initramfs as generated by mkinitrd
can't even do this, just another reason to find and apply the cluebat.

[0] : Of course, then there's all the crap with dm, md, iscsi, nfsroot,
whatever etc. that isn't really interesting and not really hard either
since most of this can also be driven by one-line udev rules.

[1] : Or device name though it should never ever be necessary to use
      device names.

> But then actually using the 
> devices that appear to boot might be more challenging, unless the device 
> names haven't changed since mkinitrd time.

I'm not sure what this means. One should always use UUID, if that's not
available use LABEL. All but exotic file systems (jffs2 - hi dwmw2!)
supports this. Of course if you change LABEL / UUID then it's your own


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]