Re: firmware and initrd [was Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts]

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

On Fri, Feb 25, 2005 at 03:29:11PM -0800, Patrick Mansfield wrote:
> On Thu, Feb 24, 2005 at 10:43:43PM +0100, Erik van Konijnenburg wrote:
> 
> > Some thoughts on how this should work.
> > 
> > - The easy case is where everything is modular.  If there's a dependency
> >   on firmware_class, bingo, we need firmware support.
> 
> But not necessarily in the initrd.

Correct.  However, if one of the modules needed to boot depends on
firmware_class, it's *possible* that the firmware is necessary to
boot.  Thus, to play it safe, you'll want the firmware on the image.

> > - This does not cover the case where firmware_class or caller is
> >   compiled into the kernel.  Note that if a caller is compiled in,
> >   firmware_class must also be compiled in.  We track kernel defines;
> >   bingo if CONFIG_FW_LOADER=y.
> 
> Do you mean if CONFIG_FW_LOADER=y, we don't support firmware loading in
> initrd? Why not? Is driver init happening before initrd is ready?

I meant the reverse: if FW_LOADER=y, it's possible that firmware will
be needed to boot, so the firmware should be on the image.

> There could be an option to the initrd generator to add firmware files, or
> to behave as if driver X were built as a module (depending on if or how you
> figure out firmware to driver mappings).

Yep.  However, command line options for the generator are a pain
for the sysadm who has to manage a farm of heterogeneous hardware.
To be avoided if at all possible.

> ...
> > - Interpreting the modules to determine which particular firmware
> >   file is needed (MODULE_FIRMWARE) is error prone: there are too many
> >   opportunities for the driver author to come up with creative ways to
> >   break the interpretation.
> 
> The driver writers/maintainers already have to specify the name of the
> firmware file somewhere in the driver, it is not much more work to add a
> matching MODULE_FIRMWARE. We can also have multiple MODULE_FIRMWARE lines
> in one module.
> 
> > - On the other hand, it would be reliable and fairly simple to put a
> >   wrapper around the firmware file and annotate it with the devices it
> >   supports.  (For example, put it in mime/multi-part format with base64
> >   encoding for the payload, plus some patterns in the header modeled
> >   on modules.alias.  Or wrap it in XML and claim SOAP conformance.)
> 
> Or just add to some sort of modules.firmwaremap file? Then no wrappers
> around the firmware files are needed, but the rpm or installer pieces need
> changes. I still like a MODULE_FIRMWARE so such a file can be
> auto-generated (or just dump modinfo output in the ya/mkinitrd).
> 
> Maybe under /lib/firmware (I don't know if that is appropriate). It would
> only be used by the initrd generator.

You're right, module.firmwaremap is easy to generate.  What worries me
about it is a migration issue: how is the initrd generator to know
whether every module has all relevant MODULE_FIRMWARE statements
added?

Consider the case where module A and B both need firmware C.  A has
MODULE_FIRMWARE, B does not, and B is included on the image.  The
initrd generator finds no indication firmware C should be included:
a non-booting image results.

This migration problem disappears when you add an annotation to the
firmware that indicates what devices it's needed for (Note the use of
devices rather than modules).

It also allows the initrd generator to be a bit more precise;
consider for instance Andrews proposed qla2xxx driver.  This would
load q12100_fw.bin .. q12322_fs.bin, depending on the hardware model.
With MODULE_FIRMWARE, all firmware files would be referenced by the
module, all firmware would need to go on the image.  With firmware
annotated with device type, only the the firmware that matches the
actual device would need to go on the image.

[ Note to self: annotating the firmware does not have to be done with
a wrapper around the firmware file.  It's much easier to have the
annotation for /lib/firmware/q12100_fw.bin in a separate file, eg
/lib/firmware_info/q12100_fw.bin.  This way firmware.agent does not
have to be modified.  The important thing is that the annotation is
related to the firmware, not to every module that may use it. ]

Anyway, in today's image generators, firmware is not supported at all.
Let's get back to these space optimisations after we've fixed that.

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