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