Re: [RFC] binary firmware and modules

[Duncan Sands <duncan.sands@math.u-psud.fr>]

On Tuesday 18 April 2006 15:16, Jon Masters wrote:
> On 4/15/06, Jon Masters <jcm@redhat.com> wrote:
> 
> > 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.

Hi Jon, 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.

Ciao,

D.