Messages in this thread | | | From | Duncan Sands <> | Subject | Re: [RFC] binary firmware and modules | Date | Tue, 18 Apr 2006 15:37:46 +0200 |
| |
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. - 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/
| |