Posted by: Anonymous Coward
on November 11, 2006 09:50 AM
I think that Theo de Raadt (yes, "Mr. Abrasive", I know) has the right idea here. His take on device firmware is as follows.
You have, say, a wireless network card. That wireless network card has its own CPU (e. g. an ARM processor) and DRAM that exists and runs totally outside the context of the computer's main CPU (e. g. an AMD Opteron or PowerPC G4). That wireless NIC's own CPU has its own OS, called a "firmware." That firmware runs on the wireless NIC's CPU, *not* the system's main CPU, and thus not in the OS's kernel.
Traditionally, that firmware has been stored in a flash device. Due to cost-cutting measures, manufacturers went to cheaper DRAM to replace the flash, and the OS's device driver loads that firmware into the device's own DRAM (*NOT* the system's main DRAM). It's the same as before, from the OS's perspective; it's just like using traditional flash memory, but with a less-expensive manufacturing cost.
Therefore, we don't really need the source code for that firmware image. We are not--generally speaking--ARM assembly-language programmers; we are C programmers who hack on the OS kernel (e. g. Linux, or the OpenBSD kernel). What we *do* need is the unrestricted ability to *distribute* that firmware image with our Free Software OS. That's all. Now, that said, if the wireless NIC's manufacturer *does* wish to release the source code for that binary firmware image, we certainly wouldn't object.<nobr> <wbr></nobr>:-) However, it is not by any means needed for our purposes.
The other thing that we need are the programming specs for said wireless networking card. Again, no firmware source code is needed. Just give us a specs document telling us how to write operating system drivers for it.
Those two things are all we need. As Edgar Allan Poe said, "only this and nothing more."
That is Theo's position. I think that it is a technically correct, as well as practical, one. Manufacturers that allow these two things do indeed have their binary firmware images distributed on the OpenBSD CD-ROM, for that reason. I therefore see no problem with them being distributed with gNewSense, either.
Learn about Linux
Download Linux
Get Linux help
Re:Hmm
Posted by: Anonymous Coward on November 11, 2006 09:50 AMYou have, say, a wireless network card. That wireless network card has its own CPU (e. g. an ARM processor) and DRAM that exists and runs totally outside the context of the computer's main CPU (e. g. an AMD Opteron or PowerPC G4). That wireless NIC's own CPU has its own OS, called a "firmware." That firmware runs on the wireless NIC's CPU, *not* the system's main CPU, and thus not in the OS's kernel.
Traditionally, that firmware has been stored in a flash device. Due to cost-cutting measures, manufacturers went to cheaper DRAM to replace the flash, and the OS's device driver loads that firmware into the device's own DRAM (*NOT* the system's main DRAM). It's the same as before, from the OS's perspective; it's just like using traditional flash memory, but with a less-expensive manufacturing cost.
Therefore, we don't really need the source code for that firmware image. We are not--generally speaking--ARM assembly-language programmers; we are C programmers who hack on the OS kernel (e. g. Linux, or the OpenBSD kernel). What we *do* need is the unrestricted ability to *distribute* that firmware image with our Free Software OS. That's all. Now, that said, if the wireless NIC's manufacturer *does* wish to release the source code for that binary firmware image, we certainly wouldn't object.<nobr> <wbr></nobr>:-) However, it is not by any means needed for our purposes.
The other thing that we need are the programming specs for said wireless networking card. Again, no firmware source code is needed. Just give us a specs document telling us how to write operating system drivers for it.
Those two things are all we need. As Edgar Allan Poe said, "only this and nothing more."
That is Theo's position. I think that it is a technically correct, as well as practical, one. Manufacturers that allow these two things do indeed have their binary firmware images distributed on the OpenBSD CD-ROM, for that reason. I therefore see no problem with them being distributed with gNewSense, either.
#