Forgot your password?
typodupeerror

OpenBSD Ahead of Linux for Wi-Fi Drivers 256

Posted by timothy
from the alle-menschen-sind-auslaender-fast-ueberall dept.
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.'"
This discussion has been archived. No new comments can be posted.

OpenBSD Ahead of Linux for Wi-Fi Drivers

Comments Filter:
  • yay for BSD (Score:4, Interesting)

    by Umbral Blot (737704) on Monday June 12, 2006 @04:17PM (#15519269) Homepage
    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.
  • Bootable Distro? (Score:2, Interesting)

    by deadhammer (576762) on Monday June 12, 2006 @04:24PM (#15519311)
    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.
  • Re:This seems bogus (Score:3, Interesting)

    by grub (11606) <slashdot@grub.net> on Monday June 12, 2006 @04:24PM (#15519313) Homepage Journal

    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.
  • Re:This seems bogus (Score:4, Interesting)

    by aristotle-dude (626586) on Monday June 12, 2006 @04:25PM (#15519316)
    I think it is a combination of laziness and philosophical issues. Linux is being held back by both unfortunately.
  • confused... (Score:3, Interesting)

    by Lumpy (12016) on Monday June 12, 2006 @04:28PM (#15519336) Homepage
    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?
  • Re:Ha, wireless BSD (Score:5, Interesting)

    by ArbitraryConstant (763964) on Monday June 12, 2006 @04:33PM (#15519366) Homepage
    I went to a presentation by the OpenBSD developers during their Hack-a-thon, and they indicated that WPA was not a very high priority for them. They prefer to do authentication with auth-pf, and if encryption is needed they prefer to use VPNs. It does make it a PITA if you want to use a network you have no control over, but the OpenBSD crowd are like that sometimes.
  • by Homology (639438) on Monday June 12, 2006 @04:38PM (#15519426)
    > BLOBs are bad, and their legality in the kernel is questionable.
    > Of course really free drivers that let us extend devices are better.

    It would be helpful if the Linux developers would be more supportive
    of OpenBSDs work on getting hardware manufactures to release
    documentation that is not under a NDA. When OpenBSD had the campaign
    for release of wi-fi chipset docs, it seemed that the Linux developers where
    sitting on the fence.
  • by SigILL (6475) on Monday June 12, 2006 @04:42PM (#15519448) Homepage
    What would end the argument, Bruce is open-source hardware.

    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 [theaimsgroup.com]. Companies like intel and texas instruments still don't want to cooperate. Something to keep in mind when purchasing new hardware perhaps.
  • by schweini (607711) on Monday June 12, 2006 @05:11PM (#15519682)
    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?
  • by SigILL (6475) on Monday June 12, 2006 @05:28PM (#15519798) Homepage
    Hm. There are two issues here and I'm a bit confused regarding which you mean.

    Place-and-route for the logic to load into the device.

    My impression is that Open Source does exist to do at least part of this job. I don't know how good it is.

    I know of free (libre) VHDL synthesis software targetting silicon (eg. Alliance [lip6.fr]), 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 [xilinx.com] (which is gratis for their lower-end devices) for a couple of years now, but it is still being outperformed by more [synplicity.com] expensive [mentor.com] software [synopsys.com].
  • by LWATCDR (28044) on Monday June 12, 2006 @06:01PM (#15520011) Homepage Journal
    Yes in an ideal world. WiFi devices have an additional problem. They must be certified by the FCC. A lot of the devices now use a software defined radio. That is great since it brings down the cost of the card and makes it more flexible. The problem is that if the end user has access to the interface in theory the end use could enable the device to broadcast out of the legal limits. The FCC would fail to certify that device.
    Yes you could make cards that enforce the legal limits of power and frequency but that would make the device more expensive and frankly give the end user no real benefit except that you can have an open source driver for it.

    The real solution is to admit that we live in an imperfect world and provide a stable binary device driver interface for Linux. Hardware providers could then include binary Linux drivers with their hardware. Right now even if a company wanted to include a precompiled driver for a piece of hardware it really is impractical. There is no way of knowing if it will work with what ever version of the kernel the user may have installed. You may say that they should open source the driver but that doesn't change the issue. They could release the driver as OSS but that still will not allow the manufacture of the device to include a precompiled version with the device.

    The lack or refusal to include a stable binary device interface is an artificial method too try and force hardware manufactures to release OSS drivers at the expense of the end users.
    The fact that Nvidia provided binary drivers shows that it doesn't work.
    Just as people with Windows may want or need to run FOSS under a closed source OS. Some people want or need to run Closed Source software under Linux.
    I would love to have a 90% free software stack including Linux. Instead of a 60% free software stack under Windows.
  • Open Source Hardware (Score:5, Interesting)

    by jd (1658) <imipak&yahoo,com> on Monday June 12, 2006 @06:12PM (#15520069) Homepage Journal
    I do believe that this is the correct direction and that OpenCores has a lot of very useful material. There are programs for hardware analysis and design, but you are correct that there's a LOT more to hardware than just that. Even with high-end commercial applications, it is not easy - the software can easily fail to calculate the power loads, for example, leading to both over-hot regions and under-powered sections.


    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.

  • by Burz (138833) on Monday June 12, 2006 @06:15PM (#15520089) Journal
    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/ [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 [berkeley.edu] 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.
  • by herodiade42 (974875) on Monday June 12, 2006 @07:56PM (#15520621)
    I fully agree, indeed the Linux developers are innocent there. By no means I was charging them: they are the one who actually write the free softwares !

    And yes, commercializers are guilty ; but, to some extent, their user community have a responsability too: they (the users) had means to make commercializers/distros change their mind. They didn't, despite TdR and RMS calls for help.
    That's why I'm talking about this here, I want this little slashdot post contribute to pass the message among free software users: we're responsible too. When needed, we should educate our software providers (aka commercializers aka distros), we should tell them that we expect them to play the rules fairly. They'll listen us, we're the user base, and after all, we're also their marketing & PR force.
  • Re:yay for BSD (Score:3, Interesting)

    by try_anything (880404) on Tuesday June 13, 2006 @03:26AM (#15522324)
    IANAL, but my impression is that no one claims that clean room reverse engineering has ever been required by law anywhere at any time. The clean room method is designed not merely to comply with the law but to be a convincing demonstration that the requirements of the law have been met. Abiding by the law is one thing; being able to cheaply and confidently defend yourself in court against a well-funded attack is another thing entirely.

    (Further, if clean room engineering is the de facto standard for documenting compliance with the law, people are likely to assume that the only reason for doing it any other way is to conceal wrongdoing. That attitude may have little to do with the law, but it might have some influence in a courtroom. On that point I'm out of my depth; ask a real lawyer.)

  • Re:Ha, wireless BSD (Score:3, Interesting)

    by greenrd (47933) on Tuesday June 13, 2006 @06:46AM (#15522785) Homepage
    This whole "you could be sued for reverse engineering" thing is a load of crap. Who in reality has been sued for reverse engineering? Even in the US you are allowed to reverse engineer for interoperability purposes. You can be sued for infringing on a patent, but that's not specific to reverse engineering.

  • Deviceescape (Score:2, Interesting)

    by octopus72 (936841) on Tuesday June 13, 2006 @07:41AM (#15522929)
    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.
  • by squiggleslash (241428) on Tuesday June 13, 2006 @10:42AM (#15523862) Homepage Journal
    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.
    That's one way of doing it, and is only necessary if it's not possible to determine how a device works by examining its operation (ie you must have someone see source code)

    The OpenBSD 3945abg driver, on the other hand, was reverse engineered by taking the open source component, modifying it (in accordance with the GPL), and having that essentially spy on the binary-only proprietary daemon, allowing the author to determine what registers are used and how they're used. Technically the author "saw" the GPL'd driver and then wrote a BSD driver, so a very, very, stretched case could be made that the author may have unwittingly copied code and be relicensing it in violation of the GPL, but obviously for a Linux developer, this wouldn't be an issue as the Free Software driver would fall under the GPL anyway.

    I've had to reverse engineer stuff before. I generally find it easier to grab a hex editor and look at the input and output of a proprietary module than disassemble code which typically results in hundreds of thousands of lines of cryptic, undocumented, uncommented, not-even-self-documenting, code to examine. If you have a rough idea of what needs to be in the output of some code (for example, three or four sets of coordinates representing a spline in an outline font), you can start to build a bigger picture relatively easily.

    No disassembly required.

    No copyright lawsuits possible.

"More software projects have gone awry for lack of calendar time than for all other causes combined." -- Fred Brooks, Jr., _The Mythical Man Month_

Working...