Messages in this thread | | | Subject | Re: [RFC] binary firmware and modules | From | Marcel Holtmann <> | Date | Tue, 18 Apr 2006 16:22:51 +0200 |
| |
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/
| |