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 ..>