Re: [RFC] binary firmware and modules

[Marcel Holtmann <marcel@holtmann.org>]

Hi Duncan,

> > > The attached patch introduces MODULE_FIRMWARE as one way of advertising
> > > that a particular firmware file is to be loaded - it will then show up
> > > via modinfo and could be used e.g. when packaging a kernel. I've also
> > > given an example via the QLogic gla2xxx driver.
> > 
> > Ok. If nobody shouts today I'm going to suggest this go into 2.6.17. I
> > think more ellaborate schemes will come up later, but we also need
> > something usable out there now.
> > 
> > As others have pointed out, cunning schemes to hack how
> > request_firmware et al work are all very well and good, but often we
> > just don't know what firmware we'll need until runtime. Unless or
> > until there's a good way to address that, I think modules will need to
> > advertise every firmware and distros will have to package all possible
> > firmwares, just in case.
> 
> this approach seems mistaken to me.  If I understand it right, 
> your mental model is that the driver has a list of file names for firmware
> files, and calls user-space with the right file-name for the device in
> question.  Given that model, having drivers tell the world about their
> firmware file list is reasonable; but I think the model is a bad one.
> Much better would be to have drivers work at a higher level of abstraction,
> and have user-space map the driver's abstract firmware request to a
> particular firmware file.  The kernel should say: I am the x driver,
> I want firmware for the y device, my version is v, the device version
> is r, etc etc.  Userspace should work out that the appropriate file
> is ql2322_fw.bin and upload it.  This is similar to the way the kernel
> handles other requests for services, such as loading modules (the kernel
> can ask for a particular module, but it can also ask for a module which
> provides a certain functionality).  Of course this requires making udev
> firmware handling more intelligent.
> 
> I gave the example of the speedtouch driver to show how complicated
> things can be.  I didn't mean to suggest that the scheme it uses is
> a good one - it is a bad one, in that the real solution is to make
> userspace smarter.  In any case, I don't see how your suggested patch
> could reasonably work with the speedtouch driver - after all, the
> driver doesn't have a list of possible firmware files, and can't
> have one because no-one knows exactly which files exist or may be
> needed; and even if I had a decent list, I think it would be a mistake
> to hardwire it into the kernel.

we have two kind of devices that need firmware download. The easy and
clean ones which need one or two files and these basically change not
that often. In most cases these are the network or storage devices and
for exactly these we need the MODULE_FIRMWARE() support to know which
files have to be put into initrd.

The messed up devices like the Speedtouch and maybe even some WiFi
dongles are another story.

Regards

Marcel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/