Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts

[Erik van Konijnenburg <ekonijn@xs4all.nl>]

On Fri, Feb 18, 2005 at 01:50:58AM +0300, Roman Kagan wrote:
> On Thu, Feb 17, 2005 at 09:06:20PM +0100, Erik van Konijnenburg wrote:
> > This is to announce yaird, Yet Another mkInitRD, a rewrite of mkinitrd
> > based on hotplug algorithms.
> 
> What do you think will its target user base be?
> 
> I'm just trying to figure out why a user of such a utility (i.e. we're
> not speaking of embedded world) wouldn't be able to afford an initramfs
> image of up to, say, 8 MB.  Then, with gzip -9 giving a factor of 2.5+
> compression on the cpio archive of the modules tree, you can perhaps fit
> all the modules (well, sound can be thrown away) and the hotplug stuff
> from the live system into initramfs.cpio.gz.

Good question, that may be relevant to the hotplug next generation
discussion.  Once you accept the idea of a 2.6-only initrd builder,
the choice is between:
- the classical method: pre-compute required modules and put only
  those on the image,
- or the radical approach: put it all on the image and let hotplug
  sort it out at boot time.

There is an extra cost in putting everything on the image, but that
may be worth it if it means less maintenance, less problem reports or
faster boots.  Here's an attempt to sort out the strong and weak points:

- The main argument in favor of the radical approach is that it can
be more resistant to hardware changes: if /dev/sda decides it wants
to be known as /dev/sdb after a reboot, hotplug can accommodate that.
Is this something that bites users, and are there many cases where
hotplug handles this without need for a recovery disk?  [that's not
a rethorical question; I'd appreciate an estimate from someone with
more overview than me.]

- The radical approach depends on a rewrite of hotplug without shell
scripts (it's very difficult for mkinitrd to determine reliably which
executables are needed by a shell script).  That seems to be in the
works, but the catch is that that needs to be done in such a way that
it can handle the mounting of a new root file system without leaving
dangling references to the old rootfs; I think at the moment that issue
is unresolved, but once it is, it will no longer be an objection to the
radical approach.

http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m\x110530801407386&w=2

- More serious may be the use of PROGRAM="..." in udev.rules; this again
sucks in executables and shell scripts that make it difficult to find
out what should go on the image.  It may be possible to write a
separate rules file for use on initrd that avoids the PROGRAM="...";
it would help to make the rule format richer, so that more cases can
be handled without resorting to PROGRAM="...".

- Finally there is the issue of boot times.  Does udevstart depend on
ide-probe and loading and unloading of IDE modules to detect legacy
devices?  If so, that can't help in the race for the fastest boot
time.

At the moment I see no clear winner; lets just build both approaches
and see which one works best.

As an aside, yaird can support the radical approach just as well as the
classical approach.  For radical images, it would add LVM, mdadm and
file system support; the hardware detection would be done by a coldplug
in the prologue of the /init script.  The only change required to the
software is adding wildcards to the file list in the templates: add a
complete /lib/modules tree to the image rather than individual files.
If you want to use yaird to add LVM and mdadm support to experiments
with radical images, let me know and I'll add the wildcard thingy.

Regards,
Erik




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel