Cc: Jeff Garzik <jeff@...>, Linus Torvalds <torvalds@...>, <david@...>, Arjan van de Ven <arjan@...>, Andrew Morton <akpm@...>, <alan@...>, <linux-kernel@...>
On Tue, 2008-07-15 at 14:58 -0400, Theodore Tso wrote:
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
--
