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

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

On Tue, Feb 22, 2005 at 11:03:58PM +0300, Roman Kagan wrote:
> On Tue, Feb 22, 2005 at 11:26:09AM -0800, Patrick Mansfield wrote:
> > On Tue, Feb 22, 2005 at 02:51:10PM +0300, Roman Kagan wrote:
> > 
> > > BTW one more item to track the dependencies for (in case you don't have
> > > enough :) is the firmware files.
> > 
> > Maybe we need in module.h:
> > 
> > #define MODULE_FIRMWARE(_firmware) MODULE_INFO(firmware, _firmware)
> > 
> > And use it for any module that can generate a call to request_firmware().
> > (Too bad we can't hook right into request_firmware(), since some callers
> > pass variables as the name.)
> 
> That's the problem here as well: you'll have to manually keep
> MODULE_FIRMWARE in sync with what you actually pass to
> request_firmware().

I haven't really looked at firmware yet, so the following may be 
off the mark, but:

- one approach would be MODULE_FIRMWARE, perhaps in the form of an array,
where every firmware file that's potentially interesting to the module is
listed.  This way you can build the leanest initrd images possible;
it will also fail to make us wildy popular with out-of-tree driver authors.

- another approach is to let mkinitrd/yaird note a dependency on firmware
class, and if present put *all* of firmware on the image.  Yaird would need
to support wildcards for that (put a whole tree on the image, not individual
files), but that's needed anyway to allow experiments with hotplug on the
image.  If the firmware directory is small, this may be good enough.

- a hybrid, where the default is to put all firmware on the image,
but we design some optional MODULE_FIRMWARE magic to allow the module
author to make a statement that only certain files are needed.  
This could get tricky for situations where firmware is loaded by a common
support module, firmware loaded via ioctls or firmware specified via module
options.

Let's build the second solution first, then consider the third one once
there's data that shows it would provide significant benefits.

> > Why is there no file system reader (like grub has)? So the initrd could just
> > copy files off of a file system as needed without mounting them.
> 
> Alternatively grub can perhaps be taught to use its filesystem reader
> and generate initramfs on the fly from /bin, /etc, /lib, /sbin of the
> actual root filesystem.  This may be slow, though...

I'd like to get yaird to a point where you can but three USB sticks in a raid
set, put an encrypted file system on it and expect it to boot.  (A wonderful
platform to test mdadm error recovery ...)

Grub has a very limited file system reader that cannot support such
sillyness, and given the primitive facilities it has to use, that limitation
makes good sense.  Other bootloaders are even more limited.  The kernel
on the other hand needs flexibility to introduce new filesystems whenever
someone comes up with a plausible story on LKML.

Consider initrd/initramfs as an isolation layer that allows bootloader and
kernel to innovate independently.  If initramfs were to require
access to the root filesystem to get to user mode, that would place
limitations on what filesystems the kernel can support, and so defeat
the purpose of having an initramfs in the first pace.

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