All firmware isn't equivalent. When the "firmware" is downloaded into an attached device, that binary blob doesn't necessarily have any correspondence to the local host architecture above the pci or usb layer. It could be FPGA core, or assembly for some custom embeddded controller. Not necessarily a nice von Neumann machine with an O/S. Having the source doesn't help without a detailed knowledge of the device architecture (what device pins do), and the build tools are highly specialized.
This is very different from binary *drivers* (like NVidia) where the binary is executed on the local host, directly in the kernel. The closed driver situation is certainly evil, since it creates a black hole in the kernel where untraceable bugs can fester.
I don't this should apply to embedded (O/S external) firmware - the execution framework is seperate. The kernel folks (and distro's) aren't going to start distributing esoteric build systems to create binary blobs for custom devices (even if such build systems were open source). The device drivers should be open - but I think it's rational to distribute supporting device firmware with an otherwise open O/S.
Just a counter opinion.
-Bob Arendt
Gregory G Carter wrote:
Just to chime in here, I think firmware should be kept out of the kernel, unless it is GPL'ed.
That is I shuld be able to use a freely available cross compiler such as the gcc tool chain and generate the binary for the hardware.
If manufactures feel it will sell more hardware by keeping it closed and proprietary, let them think that and cater to the Windows admins of the world. (Who, for the most part probably do not even know what firmware is, what it does or why it is important either way.)
<.. snip ..>