OpenBSD Ahead of Linux for Wi-Fi Drivers

algae writes "It looks like some kernel developers have noticed that the OpenBSD project is including reverse-engineered drivers for wireless ethernet cards while Linux is still using binary blobs. A large part of the issue is that much OpenBSD development takes place abroad, where having to do clean-room reverse-engineering isn't as important." From the article: "Christoph Hellwig took another stance, 'please don't let this reverse engineering idiocy hinder wireless driver adoption, we're already falling far behind openbsd who are very successfully reverse engineering lots of wireless chipsets.'"

Comments

Take Action

[neonprimetime]

Far too many people have a careless 'U.S.A. laws suck, merge it anyway' attitude

Sometimes, like at this point, it's the right attitude. They better take action soon, or openbsd will make them look like a joke.

Re:Take Action

[herodiade42]

> Far too many people have a careless 'U.S.A. laws suck, merge it anyway' attitude
Sometimes, like at this point, it's the right attitude.

I second this. IP owner are kinda terrorists (presuring gvt agencies, senates, parliaments, etc), and succeed well in spreading fear. There's lot of irrational going on this matter:

• There's already drivers reverse engenered & implemented by the same person on the Linux kernel. Accepting this one would be consitent. What's so special with wireless ?
• For mosts drivers, we don't know such details about the way it was implemented. The status quo up to now, for drivers writers is: you know that you must provide your own original implementations, we can't verify (eg. the code could be stolen from solaris, or anything) but we give you confidence, you're responsible. Why don't we credit the developers of RE drivers such a confidence, that they have done a pretty original and new implementation (that's arguably proovable on a court, then) ? that'd be consistent.
• Linux users, developers, corporations and distributions come from all over the world (SUSE is German, Mandriva is French ...). Linux don't try that hard to comply with zeale to all insane rules on all involved countries, but try to behave fair regarding intelectual property. So far, we weren't hurt (and for the precise case we discuse: OpenBSD didn't undergo lawsuits). It'd be consistent to adopt the same approach for the most stupid U.S. potentials but improbables risks.
• There's many pathes where the kernel can be fucked up by U.S. IP lawyers. In particular, in the patents area. Why the hell do we bother with this detail on "clean room reverse engenering" sudently ?
• When a driver is RE in a country outside U.S., what difference it makes that it's RE ?

Clean room RE is over zealous. It's inconsistent to require spending time & ressources on this.
Meanwhile, Linux devs will know that (on wireless land only !), it's controversial to do self RE. So, for instance, they will hardly write a replacment for the Intel 3945ABG binary crap (can't be done without RE). We're hooked to Intel ! we dismiss our freedom for big vendors fear. Too bad.

Re:Take Action

[maelstrom]

So what operating system has MP3, DivX, WMV, MKV, etc without installing software or codecs?

You can help end this argument

[Bruce Perens]

BLOBs are bad, and their legality in the kernel is questionable. Of course really free drivers that let us extend devices are better.

Leaving BLOBs in the kernel might just mean you have different plaintiffs than if you used a reverse-engineered driver.

However, full clean-room reverse-engineering a free driver with full source code, rather than one that you have to disassemble and figure out, is a reasonably easy task. And, we have to write a Linux driver anyway. So, find one friend to work with and get started.

One person must not write any kernel code concerned with the driver. That person must read the existing driver, document the hardware, and publish the document. The document should not reproduce algorithms in the existing driver unless they are integral to driving the device and there isn't another way to do it.

A second person must not look at the existing driver. This person reads the document and writes a new driver.

Keep notes about the entire process. You could someday have to testify that you did it the right way.

Bruce

Re:You can help end this argument

[Triumph The Insult C]

BLOB != firmware

i can hardly imagine theo was ever supportive of the idea of shipping a bsd-licensed blob with openbsd

Re:You can help end this argument

[herodiade42]

No, the problem he is talking about was not with Stallman.
In fact there were two differents campaigns goals, about two very different kinds of "blobs":

• For obtaining the right to redistribute firmwares with the system. With recent wireless chipsets, the firmware is often loaded in the hardware at runtime, so it should be provided separetly (a scale economy compared to providing a flash memory onboard). So even BSD or MIT licences were acceptables here: the firmware is to be loaded and executed on the chipset, not in the main system memory nor in the kernel. It's not ideal, but we're used to accept this with eg. PC Bios, or any other drivers. I understand that it could be non orthodox for Stallman, but this is not the vital part of what Theo asked for (it was rather secondary).
• For obtaining proper chipsets documentations and specifications so that any free OS can write his proper driver. And NOT a driver (mostly binary, but even free) from the vendor, nor specs under NDA. This was the crucial part.

But by no way the vendors provided any BSD drivers replacement for any blob (really, they don't care about OpenBSD). Some (Ralink, Atmel) agreed to redistribute the firmwares under MIT like licences anyway.
And from Theo words, Stallman was found very supportive on this work (but not the Linux distros makers & users).

The problem was with the second point, obtaining the hardware specs and not a binary "blob" driver. Theo de Raadt was replied by some vendors that (citing from memory) "you just have to sign our agreement and accept our binary blob drivers, look, many distributions (namely Mandriva, Ubuntu and Suse) agreed so it's an acceptable proposal, and you've no other choice". Theo was chocked by those replies, and chocked that only the FSF helped on his lobbying: the Linux distros makers wheren't supportive, rather the opposite, and the users of those distros didn't react to such a betrayal. It's somewhat similar to the recent Sun's Java redistribution licence for Linux (except that it's about kernel code, more sensitive).

If you're interested on this story, I can find propers links, but most of it was covered on www.kerneltrap.org and www.undeadly.org, so you'll easily find the full story.

Re:You can help end this argument

[Bruce Perens]

I don't like that Mandriva, Ubuntu, and SuSE accept that stuff either, and I agree that it works to undermine us. But you're not really talking about Linux developers. Just Linux commercializers.

Bruce

Blob is bad!

[grub]

I really hope the OpenBSD group's steadfast stance on "blob" is maintained. The Linux guys, who overall don't seem to mind blob, sound like they're starting to see the light. In the end it can only be good for all open source, not just OpenBSD.

Re:This seems bogus

[mrchaotica]

ndisWrapper isn't counted because the thing it's wrapping around is a binary blob. That's basically the opposite of a BSD driver.

Re:This seems bogus

[Homology]

I think the problem is that the BSD code may not be considered "clean room" by the Linux people, hence it's "dirty" (not my opinion) and not to be touched. You can probably trace a lot of this obsession to the SCO lawsuit.

But developing Linux drivers with documentation under NDA is popular, though.

Open Secrets

[Doc Ruby]

If those OpenBSD drivers are under the BSD license, doesn't that mean anyone (except the very few under some kind of other legal constraint for some other reason) with the chops can port them to Linux? And those chops don't have to be as tight as the original BSD coders. Shouldn't the lead be very short-lived?

Re:Open Secrets

[evilviper]

Yet the much smaller BSD developer community has enough people with even rarer skills?

No, it's that this has been an "itch" in the OpenBSD community for quite a while now. Linux developers simply chose to focus their attention elsewhere, since their wireless cards were working fine...

Re:This seems bogus

[Just Some Guy]

Yeah, because all the BSDs and Linux have identical kernel interfaces, PCI subsystems, DMA handlers, etc. A simple ./configure; make install is all that separates OpenBSD's kernel from 2.6.15, after all.

In reality, on the other hand, the reverse engineered drivers can serve as excellent documentation for how the same logic can be implemented in another OS, but that's about as close as it's likely to get.

Re:You can help end this argument-Buy foreign

[Bruce Perens]

AC wrote: What would end the argument, Bruce is open-source hardware.

Yes, that would be excellent. How do we get there? OpenCores.org has the start. However, all of the gate-arrays that they have to work with have a proprietary bitstream format and thus they require proprietary tools to program them. We need an Open Source gate-array to facilitate Open Source hardware. Initial full-custom full-wafer mass fabrication cost is about $1 Million. At that point, you can get the parts down to a reasonable price. You can do small runs in MOSIS (or whatever they have these days) to make sure the design works before you go that far.

I figure this is at least $2 Million to get done. We need good hardware designers and people to help write the grant. If I can hook up with such people, I'll do whatever I can to help. I don't have the hardware expertise to lead this, or I'd already be started. Any volunteers? I'm quite serious.

Bruce

Re:confused...

[DragonWriter]

Well, presumably, if the (paraphrased) "much BSD development is done where the law doesn't demand clean-room reverse engineering" statement really is a valid difference between OpenBSD and Linux, the legally (in some parts of the world, presumably where much Linux development is done) tainted OpenBSD drivers would remain tainted, and thus Linux developers in those parts of the world would face legal jeopardy for porting them.

Of course, if this is really the reason, the OpenBSD drivers are probably illegal for distribution or commercial use in those parts of the world, not just illegal to port.

I'm not going to comment on how valid this distinction is, since I'm far from an expert on eitehr geographical distribution of development effort on various open-source OS's or differences among international jurisdictions on legal jeopardies associated with reverse engineering.

Re:This seems bogus

[Homology]

> Drivers developed under the constraints of an NDA are usually released as blob, no? Not always. There are several drivers in the Linux kernel with docs under NDA. UltraSPARC III support, for instance. Drivers written with docs under a NDA are the open source equivalent of a blob.

Re:in other news...

[kv9]

...linux supports thousands of other devices that BSDs doesn't support.

very good. we need opensource supporting all sorts of hardware. only this discussion is in regards to WiFi support.

Linux developers are just as interested in getting opensource drivers just as the next guy. We're all in the same ship.

i don't see where the flame is. the OpenBSD folks want open unencumbered drivers (hence the 3.9 blob theme) while the Linux folks have NDIS wrappers, blobs and other such hacks. it's fact. no need to get melodramatic over anything.

and they showed us that they can deliver while sticking to their goals and principles

Re:in other news...

[mike_the_kid]

Of course, OpenBSD is a much smaller market than the Linux market, which is probably part of why binary blobs just aren't availble for it at all -- the hardware developers just ignore OpenBSD entirely rather than throwing them a bone in the form of a binary blob.

OpenBSD doesn't have any blobs because the project's leaders will not consider using them. What's the point of having an open source, audited, secure operating system if you allow arbitrary blocks of binary code into the kernel?

The reason OpenBSD doesn't have blobs is not because of their size -- they could port FreeBSD blobs in easilly. The reason is that the project is focused on quality. Their view is that quality and openness go hand in hand. Can't have one without the other. See this interview with Damien Bergamini, who implemented a driver for the Intel 3945 802.11abg NIC without any of Intel's blobs. The OpenBSD driver is considerably fewer lines of code than Intel's. Because its simpler, its easier to audit, and easier to find bugs in. Of course, you can't find any bugs in Intel's driver because you can't see the source code. Not because the Intel driver is bug free.