From mboxrd@z Thu Jan 1 00:00:00 1970 From: Erik van Konijnenburg Date: Sat, 19 Feb 2005 02:00:53 +0000 Subject: Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts Message-Id: <20050219030053.B22087@banaan.localdomain> List-Id: References: <20050217210620.A20645@banaan.localdomain> In-Reply-To: <20050217210620.A20645@banaan.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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&m0530801407386&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_id396&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