OpenBSD Journal

unfree drivers

Contributed by phessler on from the Live Free or Die dept.

Recently, there has been talk about binary driver support, and incorporating NDA'd drivers because of unfree documentation. For the most part this isn't an issue, because most vendors do distribute the appropriate documentation. However, a very small number of vendors have been refusing to release free documentation, instead requiring users to use binary only drivers, or requiring developers to sign NDAs before they can get info.

Theo mentioned: "This is a very very small subset of things that are not supported, and we have to take on industry after industry. We took on ethernet, and won. We took on scsi, and won. We took on raid, and won."

What you can do: http://marc.theaimsgroup.com/?l=openbsd-misc&m=109519653610773&w=2

Reasons why unfree drivers aren't allowed in the tree: http://marc.theaimsgroup.com/?l=openbsd-misc&m=109519932105627&w=2

In short:
* Most devices are supported, because almost all vendors are good about documentation
* Go complain to the closed vendors
* Find an alternate product, and tell the closed vendor about it
* Shut up and try to write it yourself
* Pay someone to reverse engineer

If you have pertinent contact information for these vendors, please feel free to post it in a reply.

(Comments are closed)

Comments

  1. By Anonymous Coward (142.166.108.150) on

    Personally, I just avoid purchasing devices that don't have open documentation or drivers. I much prefer OpenBSD's uncompromising approach to such things. Better no support with an explanation that the device is closed and proprietary, than buggy closed drivers that break when you upgrade your system. Such things just make the whole OS look bad -- hardly worth compromising your principles.

    It is unfortunate that binary only driver support has been making so many gains (acceptance-wise) in the Linux world. In the long term nothing good will come of it.

    Comments

    1. By mirabilos (212.185.103.56) tg@66h.42h.de on http://mirbsd.de/

      I'm also sick of the whiners who tell me they'd use MirOS or OpenBSD
      (or even NetBSD) "if it had nVidia drivers".

      I'm regularily telling them to shut up and ask nvidia themselfes (I
      even mailed them (for OpenBSD drivers), but didn't get a reply at
      all), but all they can do is whine and continue to use GNU/Linux or
      Windows.
      (Well, maybe they're better off with that, but then, some of these
      are actually quite knowledgeable in Unices and just too lazy to dual-
      boot when wanting to play some first person shooter (I do), that's
      why it's a pity.)

      Good Luck!

      Comments

      1. By mirabilos (212.185.103.56) on

        Thanks to Daniel for the "Plain Text" Option!

      2. By Anonymous Coward (142.179.200.15) on

        Nice, now all we need is DRI in the kernel to actually use it ;-).

        Comments

        1. By mirabilos (212.185.103.56) on

          DRI is the userland part; you can actually enable it in the tree
          (look at XF4/xc/config/cf/OpenBSD.cf).

          The problem is: DRI looks for a suitable DRM (kernel module) and
          just blanks the screen (eg. xlock -mode gears) if it doesn't find
          one, instead of using MesaGL as usual.

          Another problem: there are a couple of DRMs in XFree86, but they
          use the FBSD bsd.kmod.mk, not our bsd.lkm.mk - no workee...
          (I don't think they'd compile anyway.)

      3. By Anonymous Coward (208.252.48.163) on

        I'm regularily telling them to shut up and ask nvidia themselfes (I even mailed them (for OpenBSD drivers), but didn't get a reply at all), but all they can do is whine and continue to use GNU/Linux or Windows.

        Sounds like a great way to get people to switch. *groan*

        Comments

        1. By Fábio Olivé Leite (161.114.1.185) on

          Who cares about users "switching" to OpenBSD? A thousand more whiners would not make it a better OS, and would surely deteriorate the signal/noise ratio in the lists...

          Comments

          1. By Stephen Paskaluk (129.128.138.50) on

            ... and would surely deteriorate the signal/noise ratio in the lists

            Too bad the signal to noise ratio is almost zero as it is now, at least on misc@.

  2. By phessler (208.201.244.164) on

    As seen on misc@ from Theo: 
    a few people have asked politely for a list of "targets", in order of
potential.  (of course, some other people have been utter useless turds
floating in the bowl.  they are good for nothing but flushing).

The list of targets, in order of relevance, in the 802.11g market:

	connexant
		for prism GT firmware under a BSD/ISC copyright or PD
		documentation less relevant, linux people have it
		mostly reverse engineered

	realtek G
		full documention available in a pdf file on the net
		if you are a whiner who can actually write more than
		visual basic, here's a place very worthwhile starting
		since these might become very common

	atheros
		unlikely, but they are a small company under strain
		there are efforts to reverse engineer this
		stay tuned, we hope

	intel
		driver written by someone in france
		firmware not under a BSD/ISC copyright or free
		therefore useless
		convince this monolith of lawyers to free it and
		you become hero of the month, gauranteed

	broadcom
		this will never happen, and if it did, you would learn
		why you do not want to run their utter complete crap
		nothing designed at broadcom has ever been worth anything
		anything good out of there was *bought*
		serverworks host bridge, alteon ti->bge, bluesteel ubsec
		i mean, this company is a fucking disaster

  3. By Anonymous Coward (69.197.92.181) on

    "Most devices are supported, because almost all vendors are good about documentation"

    Come on, there's no need to lie. Just having a driver doesn't mean it supported. Look at Dlink 580 quad nics, if you do any serious traffic, they stop working. Or some nics not working with multicast. GigE nics without support for interupt coalecing and the rest of the features that make high performance GigE work. Or how about the fact that there is not a single supported raid controller of any kind? Just because you can use an already configured array, doesn't mean its supported. If you won these companies over, why can't I query the status of my array? Or rebuild it?

    Pretending that bitching to vendors works doesn't make it true. They don't care about a tiny minority of people. All those millions of people buying shit from Dell is all they need.

    Comments

    1. By krh (207.75.178.228) on 

      > stop working

> not working with multicast

      If something doesn't work, file a bug report. Posting to undeadly will not help.

      Comments

      1. By henning (199.185.136.137) henning@openbsd on

        look, he's not trying to improve things, he's trying to troll, so why waste time with his pseudo-technical arguments.
        if he had actually cared he knew that, to just pick two of his pseudo-arguments, the dlink-580 (ste) issues have been solved in 3.6, and most of the drivers with multicast issues have been fixed.

        Comments

        1. By Anonymous Coward (69.197.92.181) on

          Oh baby, fixing a 2 year old bug pretty much nulifies the rest of the argument huh? "most" is exactly right. The hardware list doesn't say which GigE cards are supported and which are partly supported, it just says they are all supported. And Theo's comments would lead you to believe that all major ethernet cards are supported, when as you just admitted, this is not the case. Its nice to pick the only things you can attempt to rebut, and ignore the rest. I'm sure ignoring all the RAID controllers you don't support will help get them supported much faster.

          Comments

          1. By Anonymous Coward (213.89.247.82) on

            Im very happy with OpenBSD when it comes to hardware, i have had more than 6 NIC's and all have worked just fine, and the rest of the hardware aswell...

      2. By Anonymous Coward (69.197.92.181) on

        I can't file a proper bug report since I don't have the hardware. Its been brought up on misc more than once. I am not saying trying to be a dick, I am just saying that claiming "everything is supported" is lying. Convincing people to waste their time contacting vendors that don't give a damn by pretending there was past success is stupid. If you had so much success with intel, and adaptec, how come neither of them could release docs for ICP RAID controllers? Why is there not a single RAID controller that is FULLY supported, not just having a driver that provides some basic functionality?

  4. By Anonymous Coward (218.214.35.235) on

    Speaking of tempermental vendors who publically espouse co-operation and interoperability while privately having no genuine desire for said co-operation, how did the situation with the UltraSPARC III and Sun work out? Did they eventually come through with the design specs, schematics and so on that the kernel and crypto guys were after?

    It seems silly to me that they would be actively pursuing a path that makes their hardware less desirable to users, given that the margins on their hardware is the thing keeping their company afloat - by the same token, it will be what kills the company if it is neglected, and potential new users and operational niches ( like OpenBSD-powered firewalls and VPN boxes ) are alienated.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]