On binary drivers and stable interfaces
Posted Nov 11, 2005 14:22 UTC (Fri) by N0NB
In reply to: On binary drivers and stable interfaces
Parent article: On binary drivers and stable interfaces
As I understand it, not all firmware or binary blobs exist solely because a hardware manufacturer is unwilling to release specs for the interface. As I understand it, in the USA at least, the FCC mandates that wireless devices be tamper proof. A user is prohibited by law from tweaking such things as RF power, carrier frequency, or the coding protocol. To get a device certified for sale by the FCC the control interface must be restricted to only those the FCC allows.
So here we have the Free Software philosophy and US law at odds with each other (not for the first or only time). How can this be resolved?
I have two laptops with Atheros based 802.11b/g adapters. Madwifi works very well even though I must build the package manually on my Debian systems. The kernel complains of "tainting" when loading the modules and otherwise works flawlessly.
Do I understand correctly that the binary blob of Madwifi is code the CPU executes? Yet it still is controlling the Atheros chipset. I guess the only difference is that it occupies the main memory of my computer rather than being loaded into RAM on the device, correct? Still, I don't see how the blob affects the kernel directly as it doesn't seem to be a part of it. The wrapper is definitely connected to the kernel and it talks to the blob.
It seems the real issue is the location of the firmware code. Why is it bad if the proprietary blob happens to occupy main memory and is executed by the CPU, but things are just fine if that same blob were encoded onto the firmware and the kernel is controlling the hardware in the same way?
I'm not trolling. I genuinely want to know the difference. With Madwifi it appears we have a manufacturer working as well as they can with the kernel while adhering to USA law. I don't think they are necessarily "tainting" the kernel.
to post comments)