From mboxrd@z Thu Jan 1 00:00:00 1970 From: Erik van Konijnenburg Date: Tue, 22 Feb 2005 22:57:16 +0000 Subject: Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts Message-Id: <20050222235716.D2736@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 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_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