Messages in this thread | | | Subject | Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers. | From | David Woodhouse <> | Date | Tue, 15 Jul 2008 12:27:52 -0700 |
| |
On Tue, 2008-07-15 at 14:58 -0400, Theodore Tso wrote: > On Tue, Jul 15, 2008 at 02:44:46PM -0400, Jeff Garzik wrote: > > All of the regressions examples I am citing are cured by > > firmware-in-module, because they are all examples of problems that occur > > when you remove the ability to reproduce the same functional pieces as > > 2.6.26. > > Jeff, > > I think you've said this before, but let me try to help you > cut to the chase. You are willing to *implement* > firmware-in-the-module for request_firmware(), but you want a > commitment that David Woodhouse and Linus will accept such a patch > before you go off and write it. Is that right?
The more important question is whether _Linus_ will take it, and of course I can't answer for him.
Personally I think it's pointless. But since it's only _mildly_ counterproductive, if you really want to do it then I wouldn't actively oppose it unless it turns out to be a mess to implement, or unless it's limited to working only with the in-tree firmware.
If you implement it cleanly and optionally (and defaulting off), and if it works properly with out-of-tree firmware too (so I can build a libertas usb8xxx.ko module with the firmware included, for example), then I certainly wouldn't throw my toys out of the pram over it. Ideally, it would work for out-of-tree drivers (make M=... modules) too.
I was thinking that we could maybe post-process .ko files (which we do already for other reasons), and add a special section in them containing the firmware which is mentioned in MODULE_FIRMWARE() tags. The special section is how we do it for the kernel too. That would take a little bit of code in module.c to keep track of those sections and add them to a list somewhere that firmware_class.c can see them, and then you have to think about lifetime and locking issues.
But those were just preliminary thoughts -- I wasn't really planning to implement it so I didn't go through it in detail.
An alternative approach might be to turn firmware blobs into actual modules, which just register themselves with the firmware loader in module_init(). I'm not sure I like that approach though, and depmod wouldn't 'notice' them automatically so it wouldn't work with current userspace. I've tried to be very careful to ensure that anything we do here is entirely compatible with existing userspace.
-- dwmw2
| |