Slashdot Mirror
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.'"
I just started using FreeBSD 6.1 recently and I was surpised about the ease of setting it up. (Still not for the faint of heart, but Windows isn't either. If you want a nice custom setup that does what you want, you need a lot of time in Windows). My primary laptop is a P-III 600MHz with 512Meg RAM. An old fucker I bought for peanuts. It didn't have a network interface, so I added a Sweex wireless adapter. It shows up in both FreeBSD as Windows under RaLink 2500. (Note that Sweex is a cheapass brand, but for another product I had *excellent* support by email with them)
Linux.... Nothing... No out of the box recognition.
OpenBSD also recognised it but doesn't support WPA-PSK which I do require. FreeBSD supports WPA-PSK. I've been an OpenBSD fanboy for a long time, but I like FreeBSD equally now. Linux... well, somehow I have problems with most distributions. Either philosophical problems or technical problems :-) With *BSD, I have neither.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
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.
can be found by reading the man pages
Linux is dead. Now, when will BSD be ready for the desktop?
Weaselmancer
rediculous.
Well as the article itself says the clean room method isn't required by law. It would seem to make sense then to drop it until it is required by law, or alternately host your distribution overseas and have the developers working on the drivers be non-US residents as well, so that you are less vulnerable to US law. Wi-Fi problems are one of the reasons this laptop doesn't run Linux, although BSD is sounding cooler and cooler.
Philosophy.
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
Bruce Perens.
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.
Trolling is a art,
Fantastic, I just read through the supported chipsets and my laptop's onboard chipset is on there. So now I want to test it. Are there any decent bootable CD distros (Knoppix style) of OpenBSD that I could simply download and play with? If so I'd be more than interested in getting Windows off of it and cruising with BSD.
I'll be honest, we're throwing science against the wall to see what sticks. -Cave Johnson
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.
Trolling is a art,
I think it is a combination of laziness and philosophical issues. Linux is being held back by both unfortunately.
Jesus was a compassionate social conservative who called individuals to sin no more.
ndisWrapper isn't counted because the thing it's wrapping around is a binary blob. That's basically the opposite of a BSD driver.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
So what exactly is stopping them from download ing the BSD drivers and making a linux driver from the BSD sourcecode?
Is there some kind of problem with that?
Do not look at laser with remaining good eye.
But developing Linux drivers with documentation under NDA is popular, though.
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?
--
make install -not war
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.
Dewey, what part of this looks like authorities should be involved?
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
Bruce Perens.
netcraft will confirm it.
I have freaks! I did something right...
I take it you mean as in programmable logic? That's not much of a solution either. You still need good documentation, as reverse-engineering VHDL/Verilog code is hard (speaking from experience here).
What's maybe interesting to note here is that most asian hardware manufacturers are rather open about their hardware documentation, notably ralink and realtek. Companies like intel and texas instruments still don't want to cooperate. Something to keep in mind when purchasing new hardware perhaps.
Error: password can't contain reverse spelling of ancient Chinese emperor
> 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.
Please don't forget the software, as most intelligence for programmable logic is contained there. Developing a wafer for an FPGA is easy compared to writing synthesis/P&R software for it. Automatic place and route is a really hard problem.
I'd double that, and allocate most of it to synthesis/P&R software. Although such software obviously needs to be free (libre), I think you really want to pay people to write it or it'll never become useable.
Apart from the sheer amount of work, I have to admit it does sound like fun. Although I only have experience in targetting FPGA's (I've written a couple of microprocessor cores as well as some I/O devices), not developing them myself.
Error: password can't contain reverse spelling of ancient Chinese emperor
i've taken a large linux driver and gotten it running in free with no
source changes by defining the linux interfaces as macros and
inlines. i think the only thing that didn't just fall out was
the bit-sense of PAGE_MASK.
i don't see any reason why you couldn't do the same thing in the
other direction.
i just finished fighting with my PCMCIA WiFi card and ndiswrapper and wpa_supplicant, becasue they only choose to work when they feel like it - everything from Segmentation Faults to perfected working happens from time to time - I guess it's because of the voodoo invloved in making a windows driver run on linux, so i guess i shouldnt complain. but it still begs the question why there's no "ndiswrapper for *BSD drivers", or something along those lines. AFAIK, windows drivers have to have a rather rigid interface (NDIS?), and this might not be the case for the BSDs, but i'd still guess that it should be easier to build a wrapper for other open-source drivers than for windows drivers?
Place-and-route for the logic to load into the device.
I know of free (libre) VHDL synthesis software targetting silicon (eg. Alliance), but I'm not aware of similarly licensed P&R software targetting programmable logic. And even if it were to exist, because the problem is so very hard I don't think it's going to be any good. If a company is going to put in 25 or more man-years to write a piece of very specialist software, they're going to ask money for it, not release it under the GPL.
Xilinx has been working on their own synthesis/P&R software (which is gratis for their lower-end devices) for a couple of years now, but it is still being outperformed by more expensive software.
Error: password can't contain reverse spelling of ancient Chinese emperor
OpenCores isn't the only open hardware group. Check out www.opengraphics.org, particularly the OGD1 section. Real hardware engineers are making real hardware, and they're making it OPEN (and libre).
But calculating these values isn't enough if you're designing anything of high complexity. You then really need CFD software to model how the heat will flow around your design. It's easy to build something that is quite incapable of remaining within temperature limits.
When building network interfaces, other problems creep in. You have no control over whatever you connect your device to (wirelessly or wired) and so must provide suitable tolerences. You also have potential problems from interference generated from within the device itself. A wireless network card that jams itself is of very little use.
I'm not saying this is impossible - the University of Manchester uses Open Source tools for designing async microprocessors which are suitable for cell phones, so obviously it's possible. It has been done. The problem is in moving from "possible" to "practical". That is an area that looks interesting and - as programmable computable devices become more powerful - more open to experimentation.
One of the problems with commodity hardware is that the only reason it is cheap and useful as a commodity is that it is ultra-generalized and therefore inefficient at any given task. As such, it should be very easy to design things which are more specialized and more efficient, even without a multi-billion dollar budget. Most of that budget is going to be in cramming all possible features onto as little silicon as possible without causing a meltdown. Microcomputers were buildable because no individual user really needed the full power of a mainframe. I could easily see the next stage being people designing components and cards that aren't perhaps equal to AMD's or Intel's latest mega-product but which are perfectly good for a special-purpose embedded device.
Is this likely? I don't see why not. The 65I02 is a popular microcontroller. Yes, that is a more modern 6502 processor, and 6502s are NOT rocket-science. Open Cores is already well past the simple design of a 6502, and probably more than capable of designing fairly decent control systems with Open Source tools alone. Once you get a cottage industry going with Open Source hardware, then more advanced tools will inevitably follow.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
1) Form a consortium of major Linux vendors to build and maintain an exhaustive but relatively friendly Hardware Compatability List (HCL).
2) Spread the word that if users don't consult the HCL before purchasing new hardware, they risk a lot of compatability headaches.
3) Invite hardware OEMs to participate directly in maintaining their corner of the HCL. Under each model listing, provide a button to send user feedback (or petition) to the hardware vendor.
4) Watch as hardware vendors begin to take Linux drivers much more seriously, due to constant and coordinated pressure from consumers. Vendors will get a clear message that the days of the haphazard "plug-n-wish" habit are over, since users will avoid buying their products of questionble compatability in the first place.
OS vendors must work to keep their patrons informed about hardware suitability. There is no other way around it in the near-mid term, and we will never get to the point where most OEMs automatically accommodate Linux unless a sturdy bridge is built to organize and convey the users' purchasing interests.
I think that their site is actually http://www.opengraphicsproject.org/
Does anyone know if there are any plans/projects out there to build an actual free HDL synthesizer? Something that can go from the Verilog or VHDL to a netlist? It seems that's kind of key to all of the "open source hardware" projects; without one it's like the FSF in 1986, before gcc. You can write all the code you want but doing anything with it requires finding someone with the right commercial software.
The concept of 'hacking hardware' is an attractive one, but it's hampered by the very high cost of entry. Having a Free simulator is certainly a big step, but I think a lot of people are turned off by the fact that they can't produce a netlist of their design for use on an FPGA without very, very expensive tools. (Although I've seen references to some old [c. 1983] tools published by Berkley on tape for VAX that might still be around.) Unless I'm just confused and you can program an FPGA directly from an HDL program without synthesizing to a netlist first...?
I'd be curious to see someone who's gotten involved in hardware, particularly FPGA, programming give a breakdown of the minimum costs required to experiment and actually fabricate (not just simulate) some circuits. Maybe the perception of high cost on my part is false, in which case I'd be happy to be corrected.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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
Stop Computers/Cars Analogies on S
Indeed having it GPL counts a lot.
But still, if the driver was developed under NDA and is bloated of "magic numbers" (as often in drivers under NDA, the implementation can't contain too much comment/infos), practicaly, we're near to loose one of the fundamentals rights supposedly granted by the GPL: the right to modify and re-use it. Well, you have this right, but you can hardly use it.
In practice, source code designed to hide IP secrets is in-between normal source code and binary exec. That's why, by the way, OpenBSD devs never accept and never signs NDA, as stated there http://www.openbsd.org/goals.html for instance.
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.
Troll Like a Champion Today
You sure are. You're not allowed to remove their copyright or their list of conditions, but there's nothing in the license that says you can't add more, even ones that negate theirs.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
* And you have to give me $400,000 per copy and say "Linux rules" 100 times.
Perfectly legal.
How we know is more important than what we know.
They developed advanced wireless driver framework, which will in some time be ready to be included in linux kernel.
I'm all for it, ASAP. Practicall all linux wireless dev people agreed on it, so it's just a matter of time.
Porting drivers shouldn't be as hard, while current wireless driver model is seriously lacking.
BSD code could be very helpful for reverse engineering.