On Mon, Dec 10, 2007 at 12:57:24PM -0500, Steve Shockley wrote:
quoted text
> He's referring to firmware binaries, not software that runs on the host 
> machine's processor.  Browse around under:
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/microcode/
> 
> For example, the Atmel radio firmware's license is compatible with the 
> BSD license, but incompatible with the GPL because it can be 
> redistributed as object code only.
> 

yes, but it is so stupid, the firmware is loaded into the device and
not running in OpenBSD itself.

in the past, the microcode was normally stored in non-volatile memory
on the hardware device, let's say a NIC, but now most of the devices
require to load the firmware into RAM.  it is cheaper to do it this
way, flash chips are just too expensive for the mass market.  mostly
all of the new ethernet and wireless cards require to load an external
firmware image into the _card's_ RAM, it wouldn't be possible to
support any of these chipsets without using their firmware.

but again, there is a major difference between binary blobs and
firmware images; the blobs are loaded as code into the OS kernel, but
the firmware runs directly on the device on crappy embedded micro
CPUs.  asking the vendors for releasing their firmware source code is
just ridiculous or a nightmare since I don't even want to see this
code (we wouldn't even have the right compiler for this)...

anyway, i'm clearly against binary blobs in the kernel, and in
contrast to most of the GNU/Linux dudes i _did_ some against it by
writing ar5k, instead of pointing into the wrong direction.  this open
firmware discussion is just a joke to make the relevant discussion,
binary blobs in the OS kernel, irrelevant.

reyk