Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Announcements Software Linux

Linux Kernel Devs Offer Free Driver Development 348

schwaang writes "Linux Kernel hacker Greg Kroah-Hartman, author of Linux Kernel in a Nutshell has posted an epic announcement on his blog. This could portend increased device compatibility for Linux users, higher-quality drivers, and fewer non-free binary blobs." From the announcement: "[T]he Linux kernel community is offering all companies free Linux driver development... All that is needed is some kind of specification that describes how your device works, or the email address of an engineer that is willing to answer questions every once in a while. If your company is worried about NDA issues surrounding your device's specifications, we have arranged a program... in order to properly assure that all needed NDA requirements are fulfilled. Now your developers will have more time to work on drivers for all of the other operating systems out there, and you can add 'supported on Linux' to your product's marketing material."
This discussion has been archived. No new comments can be posted.

Linux Kernel Devs Offer Free Driver Development

Comments Filter:
  • How many (Score:5, Insightful)

    by Magada ( 741361 ) on Tuesday January 30, 2007 @07:45AM (#17812220) Journal
    I wonder how many companies will be imprudent/progressive enough to take up this offer.
  • by battery111 ( 620778 ) <battery111@@@gmail...com> on Tuesday January 30, 2007 @07:46AM (#17812226)
    Seems like a good idea, but it also seems like it would give the device manufacturers an out. "I'm sorry, but we don't officially support the linux operating system". This way they get drivers written for them for free, and don't need to provide any tech support for the device to those users who purchase it for linux. Anyone else see this happening?
    • by scenestar ( 828656 ) on Tuesday January 30, 2007 @07:52AM (#17812284) Homepage Journal
      No, those drivers would most likely be written by the community anyways.

      To me it seems more like an initiative to figure out which companies use "we don't have the staff/resources for an open driver" to keep their drivers proprietary.
      • by zootm ( 850416 ) on Tuesday January 30, 2007 @08:52AM (#17812764)

        Another way of looking at it would be as formalising the rule that "if you give us specifications, the driver will get written". A lot of the problems with free software drivers is lack of information on how a device works; if this makes it better known that all they have to do is provide some specification, it might encourage companies to submit more of them, and encourage customers to ask people to submit more of them.

        • "A lot of the problems with free software drivers is lack of information on how a device works..."

          I agree 100%. Also, there are many companies that would provide information if you are willing to sign an NDA with regards to hardware specs (ie. the manufacturer would like to be open, but their lawyers think otherwise). I think the following (from the article) helps tremendously in that regard:
          "If your company is worried about NDA issues surrounding your device's specifications, we have arranged a program
          • Re: (Score:3, Informative)

            by tomstdenis ( 446163 )
            This is just ignorant legal babble. There is a huge difference between knowing how to make something "go" and how it works internally.

            If the value of your [say] network card is how to make it read/write frames and not how it actually does it internally ... you need to rethink your market. I work for a hardware firm and we regularly give out interface specs to our customers [hint: they wouldn't buy it otherwise] but consider our designs/algorithms as intellectual and proprietary property.

            Tom
        • by Svartalf ( 2997 ) on Tuesday January 30, 2007 @09:14AM (#17813018) Homepage
          You'll need a big cluebat to get a lot of these companies to wise up. The real reason that they don't give out programming interface information is because they're listening to a lot of IP Lawyers that tell them they have to keep everything secret or it might affect future patentability of future devices (YES, I've seen that A LOT lately, doing Linux driver consulting for some of the crowd willing to do proprietary driver work...), etc.

          It's a mixture of worries about revealing possible Patent infringements, trying to slavishly follow the lawyer's advice, and a confusion as to what business they are precisely in (Software versus hardware- a lot of companies, because of the advice of their IP lawyers are confused as to what they should be doing...).
          • by zootm ( 850416 )

            Yeah, it's a pain. I've seen they've put up some NDA "protection" clauses there in order to become more lawyer-friendly, but it may still not work fully; I can't even think about how they can meet all NDA clauses in all cases, unfortunately. The fact that they specifically mention such things is a step forward, though; it shows they're willing to deal with companies on their terms so long as the work can get done.

    • by ricebowl ( 999467 ) on Tuesday January 30, 2007 @07:55AM (#17812298)

      It might give the device manufacturers an out but, more importantly, won't it equally give the Linux family an 'in'?

      The point isn't, so far as I can see, to make any profit from the scheme other than to spread the word of Linux and increase the potential compatibilities/reduce the incompatibilities.

      Plus, as a bonus for the device driver writers, it's an impressive CV when you consider the varieties of hardware that are supported by the various Linux distros and the work, and potential elegance, that goes into solving the various demands.

      It seems win-win for everyone, really. And a good, and generous, idea.

      • by david.given ( 6740 ) <dg@cowlark.com> on Tuesday January 30, 2007 @08:36AM (#17812648) Homepage Journal

        The point isn't, so far as I can see, to make any profit from the scheme other than to spread the word of Linux and increase the potential compatibilities/reduce the incompatibilities.

        In fact, this is how it's always worked --- people have been asking companies for device information for years. (I did, once; I wanted the specs for a SIM reader device so I could do a Linux driver. Did I get a response? Did I hell.) The only difference is that this announcement rephrases things in a rather more marketspeak and official manner. Instead of the companies doing us a favour, by providing hardware specs, we are now doing them a favour, by writing their drivers for them.

        It's a rather neat bit of lateral thinking.

        • by nadamsieee ( 708934 ) on Tuesday January 30, 2007 @09:54AM (#17813492)

          In fact, this is how it's always worked...

          Exactly! I think Greg made a tongue-in-cheek post on his blog and the submitter and /. editor unwittingly took it at face value (no big surprise there). It will be wonderful/funny if some corporate shills also take the blog post at face value and actually start feeding the kernel developers the information they need.

    • Re: (Score:3, Interesting)

      This way they get drivers written for them for free, and don't need to provide any tech support for the device to those users who purchase it for linux.

      I'd say that's pretty much the state of play for the majority of Linux drivers anyway. To be fair I have no way to back up that claim, but it feels that way to me.

      My guess is most printer drivers are community developed. Also Modems, and Network adapters, Hard Disks and older video adapters, and Removable Mass Storage devices. The only big 'playas' do
      • Re: (Score:3, Informative)

        As far as printers go, HP has a driver out now thats pretty slick (HPLIP). It doesn't do everything, but it does most of the personal printers. (Not to mention they make damn good printers).

        http://hplip.sourceforge.net/ [sourceforge.net]

        • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Tuesday January 30, 2007 @11:47AM (#17815164) Homepage Journal
          I've decided that HP pisses me off. They go out of their way to make sure you're not refilling ink carts (and in some cases toner) and frankly I don't think their printers are all that. Not to mention that they've all but done away with duplex modules, now you have to buy duplex printers. So if you bought a non-duplex printer and you need duplex, now you have to buy a whole fucking printer! I want a company that gives me choice, not a company that scares me into buying the full-featured product by not offering me a way to add the functionality later. And they're straight up lying if they claim that no one buys those things. Anecdotally, I've got a Laserjet 5550n behind me and to the left for which we would buy a duplex module if it were offered. Since it is not, I have to do it manually, and since I'm lazy, that makes me a sad panda. :(
    • Re: (Score:3, Insightful)

      by Speed Pour ( 1051122 )
      Sure it'll happen, of course there are companies that will be eager to treat this as a freebie...But who cares? Even a few of the companies that "support" linux aren't all that serious about it half of the time. The burden of support falls on the linux community in the end anyway. At least with an offer like this, it might encourage companies to assign one or two people to lend a hand with keeping the devices supported with the community in creating the drivers, and the support, like normal, will still e
    • Re: (Score:3, Interesting)

      by babbling ( 952366 )
      "Supporting" Linux under all circumstances, versions, and distros isn't really possible if "support" is meant to be a guarantee that the device will work. Chances are, the device will work if there's a free software driver for it and it's being used under reasonable circumstances (Ubuntu or Debian, not tinylittleunheardofdistro).

      Really, we don't want "support". We just want a guarantee that they don't know of any reason why things shouldn't work. If Dell gives us a PC that will work with Linux, they shouldn
  • Hardware ? (Score:5, Insightful)

    by Rastignac ( 1014569 ) on Tuesday January 30, 2007 @07:47AM (#17812234)
    "All that is needed is some kind of specification that describes how your device works". They also need some real hardware to test the brand new written drivers. Specifications are not enough. Who will test the real hardware with the fresh drivers in a real-world operation ?
    • Well, why not us beta testers?
      • I've never developed drivers, but I'd say it would be very hard to develop a driver for a piece of hardware a developer can't test it with!
        • Re: (Score:3, Informative)

          by Svartalf ( 2997 )
          I've done it before. It's doable in proportion to the complexity of the device. Most industrial I/O devices will be doable this way- a 3D accelerator or an iWARP channel adapter would be pretty much impossible without at least one if not multiple instances of the device in hand.
      • by rbochan ( 827946 ) on Tuesday January 30, 2007 @08:34AM (#17812632) Homepage

        Well, why not us beta testers?
        Ballmer: "We refer to them as customers."

        /try the veal

    • Re:Hardware ? (Score:5, Informative)

      by Anonymous Coward on Tuesday January 30, 2007 @07:55AM (#17812300)
      from tfa

      A few sample devices might be good to have so that debugging doesn't have to be done by email, but if necessary, that can be done.
    • Isn't this the way it's always worked? Up until now, they've either had to guess, reverse engineer, or look at specs to develop the drivers. This just seems like an awareness campaign. I'm sure the devs were always willing to develop drivers, especially when they could get their hands on the specs.
      • by Zombie ( 8332 )
        You are exactly right. This is a marketing-style announcement. Its only purpose is to try to sway hardware vendor management into releasing specs because, look here, they're getting such a great deal. Free development. You'd have to be crazy not to do it!

        In reality, that's already the way it was; release your specs, and a driver will be written. IF your hardware actually sells and enough people care.

  • Dedicated (Score:5, Insightful)

    by pzs ( 857406 ) on Tuesday January 30, 2007 @07:49AM (#17812250)
    Whatever you might say about the Linux community - that it is elitist or sanctimonious or whatever - it is impossible to ignore their commitment to what they believe in. That somebody would be willing to write device drivers for nothing, apparently just to forward the cause of a free operating system, is pretty impressive. Microsoft and Apple can match this devotion only in the ferocity with which they defend their control over their customers, in anti-trust trials and by imposing DRM.

    Peter
  • Quick Scan (Score:4, Interesting)

    by mfh ( 56 ) on Tuesday January 30, 2007 @07:49AM (#17812256) Homepage Journal
    A really quick scan [google.ca] of the price of windows driver development, demonstrates how much actual value this is for business. Now all you would need to do is pay someone to extend the drivers to other platforms! Eureka!
    • by DrYak ( 748999 ) on Tuesday January 30, 2007 @09:03AM (#17812890) Homepage
      As an example of extending to other platforms, we may cite the 3DFx Voodoo board.

      After the company collapsed, users were left with no drivers for recent windows version (XP, XP64 and Vista).
      But, the Linux drivers happened to be open source.

      So most of the work you may see on websites like http://3dfxzone.it/ [3dfxzone.it] for Windows, is mostly based on libglide and Mesa3d for linux.
      (This is also another proof that open-source enable something to survive beyond the death of it's parent company)

      Another example may be the linux USB stack, which was later ported to both the Cromwell xbox bios and ReactOS (opensource clone of the Windows NT system, cousin of Wine project).

  • This is needed (Score:5, Insightful)

    by camcorder ( 759720 ) on Tuesday January 30, 2007 @07:50AM (#17812264)
    I think this kind of action, and offer for help is needed by companies. I hope it will be touted enough. What I know is that, companies having really hard times finding skilled coders for developing Linux drivers. Most of them does not care about the specifications, as they have already patents pending for their works, but they can't actually find people to code for Linux and/or they don't willing to pay more than Windows developers for Linux developers for a smaller market.
    • ``Most of them does not care about the specifications, as they have already patents pending for their works, but they can't actually find people to code for Linux and/or they don't willing to pay more than Windows developers for Linux developers for a smaller market.''

      Then why is it that so many of them won't release specs when asked? It's not like this initiative here is anything new; the Linux community has been asking companies for specs needed to develop drivers for years. Instead, I see companies devel
  • Wonderful (Score:5, Interesting)

    by ilovegeorgebush ( 923173 ) on Tuesday January 30, 2007 @07:51AM (#17812268) Homepage
    What an outstanding idea! I especially like this (from TFA):

    If your company is worried about NDA issues surrounding your device's specifications, we have arranged a program with OSDL/TLF's Tech Board to provide the legal framework where a company can interact with a member of the kernel community in order to properly assure that all needed NDA requirements are fulfilled.
    This is intelligent, it means they're covering their backs, and even more importantly the manufacturers haven't got an excuse!

    Is this realistic though? Are companies actually going to take this offer up? If they do, the impact could be awesome (hardware compatibility that could rival Windows and/or Mac OSX)...

    Nice one!
    • Re:Wonderful (Score:5, Insightful)

      by Nasarius ( 593729 ) on Tuesday January 30, 2007 @08:02AM (#17812360)

      (hardware compatibility that could rival Windows and/or Mac OSX)
      Hmmm? Linux already supports more hardware out of the box than Windows does. I'm not talking ancient SCSI cards either; I mean components like an onboard Intel PRO 10/100 NIC from a few years ago that requires an extra driver on XP SP2, but works automagically with e100 on Linux. The only segment where Linux falls down is on very new hardware.
      • Re:Wonderful (Score:4, Interesting)

        by danpsmith ( 922127 ) on Tuesday January 30, 2007 @10:07AM (#17813666)

        Hmmm? Linux already supports more hardware out of the box than Windows does. I'm not talking ancient SCSI cards either; I mean components like an onboard Intel PRO 10/100 NIC from a few years ago that requires an extra driver on XP SP2, but works automagically with e100 on Linux. The only segment where Linux falls down is on very new hardware.

        I am sure this is the case statistically, but anecdotally I've noticed that things I don't expect to "just work" (TM) with linux oftentimes do. My girlfriend's digital camera working without a driver install really sort of surprised me as I expected it not to work at all. The same camera often requires driver installs on windows (differing per version). I'm actually quite impressed with Linux's hardware support.

    • Re:Wonderful (Score:4, Insightful)

      by keean ( 824435 ) on Tuesday January 30, 2007 @08:10AM (#17812426)
      Except Linux has supported _more_ devices than any version of Microsoft-windows for some time now. Okay so most of those drivers are for older hardware that is no longer supported by new versions of Microsoft-windows... but that doesn't change the facts. You need to qualify your statement, and say what you mean. I guess something like "Microsoft Windows gets support for some new devices more quickly than Linux"... thats about it. I am not even sure there is any truth to OSX supporting more of anything than Linux, Apple-mac hardware is all the same after all.

      Infact Linux supports more devices that any other operating system ever... and thats one of the advantages of open-source kernel drivers... they are maintained with the Kernel, so they remain usable through kernel architecture changes with zero effort from the original contributer of the device-driver. I am sure Microsoft would love to do this with windows, but of course they cannot, as they don't have the source code to the drivers they did not write themselves.

    • Re:Wonderful (Score:5, Insightful)

      by kestasjk ( 933987 ) * on Tuesday January 30, 2007 @08:41AM (#17812674) Homepage
      No-one seems to have commented on the fact that if NDA requirements are met the drivers cannot be open source. This doesn't mean fewer binary blobs, it means more.

      And what about Vista's new requirement that all hardware mustn't be compromised by hackers or else the drivers will be remotely disabled? Might a company which produced hardware which is part of the DRM stack risk being more likely to be seen as compromised if it has collaborated with the OSS community?
      • Re:Wonderful (Score:4, Informative)

        by Delkster ( 820935 ) on Tuesday January 30, 2007 @09:00AM (#17812860)

        No-one seems to have commented on the fact that if NDA requirements are met the drivers cannot be open source. This doesn't mean fewer binary blobs, it means more.
        I'm far from being an expert but I've got the impression that for example the open source 3D accelerating drivers for ATI's R200 series were written under an NDA. It really depends on the NDA. The specs can reveal things that aren't immediately apparent from the code, and the NDA may be written to protect those parts. While some companies would probably require NDAs that would effectively prevent an open source driver from being written, it doesn't automatically have to be so.
      • Re:Wonderful (Score:5, Interesting)

        by TheRaven64 ( 641858 ) on Tuesday January 30, 2007 @09:58AM (#17813540) Journal

        No-one seems to have commented on the fact that if NDA requirements are met the drivers cannot be open source. This doesn't mean fewer binary blobs, it means more.
        Open Source drivers have been written under NDA before. What this typically means is that they are write-only code. The NDA will prevent things like properly labelling constants and helpful comments, so you end up with code full of magic constants and seemingly random operations. It's basically impossible for anyone to maintain without the NDA'd documentation, so you are pretty much screwed if you want to port it to another OS or maintain it when the original author gets bored or dies.

        On the plus side, a badly written driver is marginally easier to reverse-engineer than a black box. There are a couple of WiFi chips that had Linux drivers written in this way, and now have much better OpenBSD drivers written by a combination of reverse engineering and examining the Linux code. Some of these drivers have been ported to FreeBSD and, I believe, back to Linux again.

        • It doesn't matter if what you see is a C file or a binary blob, if it isn't the plainly readable source code. The most agreed-upon standard for what open source is can be found here:

          http://www.opensource.org/docs/definition.php [opensource.org]

          The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed.

          - Section 2 of OSI's Open Source Definition

          That said, an NDA still may not make it impossible to write a driver. If the specs are under NDA

        • Re:Wonderful (Score:4, Informative)

          by Josh Triplett ( 874994 ) on Tuesday January 30, 2007 @02:18PM (#17817738) Homepage

          No-one seems to have commented on the fact that if NDA requirements are met the drivers cannot be open source. This doesn't mean fewer binary blobs, it means more.
          Open Source drivers have been written under NDA before. What this typically means is that they are write-only code. The NDA will prevent things like properly labelling constants and helpful comments, so you end up with code full of magic constants and seemingly random operations. It's basically impossible for anyone to maintain without the NDA'd documentation, so you are pretty much screwed if you want to port it to another OS or maintain it when the original author gets bored or dies.
          Some NDAs require that, true; the resulting drivers look a lot like the "nv" driver for X, which does indeed look like write-only code. (And as you suggested, it did still help the authors of nouveau [freedesktop.org].)

          However, in many cases a hardware company NDA just requires non-disclosure of the hardware documentation itself, and in particular the documentation of the hardware's internal workings. In these cases, the resulting driver generally looks like most other drivers in Linux, including useful constants and helpful comments.

          (Not commenting on the ethics of NDAs in general; just presenting information.)
    • by Ant P. ( 974313 )
      I love dragging this story out every time this comes up:

      I got a new (three years old now) mid-range prebuilt computer.
      It came with a Windows XP SP1 OEM CD. The CD lacked drivers for the sound card, the video card, the NIC and the winmodem (the store had mercifully supplied a modem driver CD, but nothing else). The sound card driver was a 30MB download of bloatware, the video card driver was nVidia and then it wanted me to install SP2. This was all back before ADSL was available in my area.
      Now at the same ti
  • by LaughingCoder ( 914424 ) on Tuesday January 30, 2007 @07:58AM (#17812330)
    I have never written drivers so I may be way out in left field here, but how close are we to being able to specify a standard driver model, with compatibility across operating systems? It seems to me that drivers are one of the biggest impediments to OS adoption. They are also a huge cost center for device manufacturers. Imagine if 99.9% of the driver code could be the same across platforms. Is this even remotely possible? Or perhaps the Linux Kernel driver developers could figure out a way to adapt Windows drivers to run, perhaps in an interpreted or emulated fashion, on Linux (ala Virtual PC). Just a thought.
    • Re: (Score:2, Interesting)

      by antdah ( 1057288 )
      Do you mean something like this? [sourceforge.net] It's been around for some time now, however, I haven't been able to try it out yet since I primarily run Mac OS X.
      • Interesting. Thanks for the pointer. Yes, that is a start, though it is only for wireless network cards. But the approach seems reasonable as it basically allows a Linux system to run Windows drivers natively. Of course this would need to be extended to the other hardware subsystems (graphics, sound, memory controllers, disk controllers, etc). I would think that might be a better way for the kernel driver guys to go than volunteering to write custom drivers for each unique piece of hardware.
        • by MooUK ( 905450 ) on Tuesday January 30, 2007 @08:48AM (#17812728)
          There are huge advantages to going the driver route rather than wrappers for windows drivers. For a start, the community can update any open drivers, whereas they cannot touch closed windows drivers. There are many to whom open drivers over closed ones is a big deal.
          • As is so often the case, your strengths are your weaknesses. Having the ability to update open drivers (a strength) means that you first must *create* open drivers (a weakness). I might also offer the alternative viewpoint that if native Windows drivers were used, when the device manufacturer fixes defects or adds features to the driver, the wrapper-based implementations automatically get those improvements without having to do anything.
    • by jimicus ( 737525 ) on Tuesday January 30, 2007 @08:22AM (#17812542)
      You've just invented OpenFirmware [wikipedia.org].

      The only small problem is that it requires slightly more intelligence (and some flash memory) in the individual device - something which manufacturers have spent the last 20 years doing their best to avoid.
      • by TheRaven64 ( 641858 ) on Tuesday January 30, 2007 @10:08AM (#17813672) Journal
        Not really. No one actually uses OpenFirmware drivers much past boot time if they can avoid it. A better example would be I2O [wikipedia.org], which proposed a split driver model. Half of the driver would be hardware-specific, and half would be OS-specific. For a graphics card, for example, the OS would load a hardware driver that would translate something like OpenGL into device commands, and an OS-specific driver that would translate whatever the native graphics API was into generic graphics API calls.

        Xen implements something like this for block and network devices, and the USB and Bluetooth specifications do something similar for a few categories of device. The problem comes with things like GPUs where each new generation provides some extra functionality that the last one didn't; you'd need to constantly update your driver model to work with the new functionality. It's not impossible, but it does require a standards body that can quickly specify interfaces to the new functionality, which is quite improbably.

    • by RAMMS+EIN ( 578166 ) on Tuesday January 30, 2007 @09:00AM (#17812858) Homepage Journal
      Well, there's paravirtualization. The drivers go in the hypervisor, which then provides a simplified and unified interface to guest OSes. The guest OSes still have to implement drivers for the exokernel, but there are a lot fewer of those than there are, say, Ethernet cards.
    • Re: (Score:3, Interesting)

      by RAMMS+EIN ( 578166 )
      Or how about standardizing hardware interfaces? I've been saying this for years, and usually people have told me it's an unrealistic expectation, but it happens in some places. For example, USB devices often comply to some USB device class, for which there is one driver that can drive all compliant devices.
    • Re: (Score:3, Insightful)

      by Lazerf4rt ( 969888 )

      how close are we to being able to specify a standard driver model, with compatibility across operating systems?

      Sorry if I sound pedantic, but we are already "able" to specify a standard driver model. I can specify one right now: the Linux driver model. It's pretty well-documented; just check out "Linux Kernel In a Nutshell" or "Linux Device Drivers" or the Linux kernel source.

      Specifying one is not a problem. It's getting OS developers to adopt it that's a problem. Microsoft obviously isn't going to adop

  • Nothing new? (Score:4, Interesting)

    by Andy Dodd ( 701 ) <atd7@@@cornell...edu> on Tuesday January 30, 2007 @08:03AM (#17812374) Homepage
    Other than the public announcement, how is this any different from the way things already work?

    The community already writes free drivers for vendors who provide specs and (even better in some cases) loan some hardware.

    There are already situations where Linux devs have been able to work out NDA-acceptable solutions.

    Really, all the announcement is saying is, "Look, we do this. We've been doing this for years. Just letting you know how things work over here."
    • by flithm ( 756019 ) on Tuesday January 30, 2007 @08:27AM (#17812582) Homepage
      Other than the public announcement, how is this any different from the way things already work?

      Actually this really is something new, and quite an announcement. It was never the case before that any old random driver would get created by the open source community. The way OSS development generally works is there has to be a strong need, strong backing, or a high fun factor, for things to get done.

      Prior to this announcement it's not like there was a group of people dedicated to writing drivers -- just waiting for companies to release new hardware, then they'd scurry to reverse engineer it and write a driver. Nor do companies (generally) release hardware specs in the hopes that others will provide a driver for their product.

      A significant portion of initial open source driver development comes from the device manufacturers themselves, and smaller companies without the resources to spearhead these developments simply don't have the ability to have Linux support.

      Your conception that "The community already writes free drivers for vendors who provide specs and loan some hardware" isn't true in the vast majority of cases.

      This really is a big change, because now anyone can create a hardware device and actually have formal linux support, and have this printed on the box. This creates a formal avenue for companies to easily, reliably, and cheaply have Linux support for their products.
    • by Alsee ( 515537 )
      Tomorrow on Slashdot, a similar offer to the RIAA, to iTunes, to Zune, and to all of the online music retailers of FREE services to help convert their music files to MP3 format.

      -
  • by Alain Williams ( 2972 ) <addw@phcomp.co.uk> on Tuesday January 30, 2007 @08:13AM (#17812444) Homepage
    The Kernel code will be publically visible, so how is ''confidentiality'' maintained ? The only ways that I can think that this will be done are:
    1. Uncommented Kernel code - Yuck!
    2. Spaghetti/obscured Kernel code - Yuck!
    3. Binary blobs in the Kernel - Yuck!
    • by simm1701 ( 835424 ) on Tuesday January 30, 2007 @08:25AM (#17812564)
      Ranked in order of preference:

      a) no driver for your hardware
      b) binary blob kernel patch created by hardware munfacturuers
      c) binary blob in kernel tree created under NDA by the kernel team (who have private access to the source)
      d) obfuscated code in the kernel tree (with original kept private to those kernel devs that have signed the NDA)
      e) uncommented code in the kernel tree (with commented code kept private to those kernel devs that have signed the NDA)
      f) fully open source driver

      Personally I'll accept anything b or above - I'd prefer d or above, would settles for c but would really like f!!

      I wonder where the compromises will be made? How far will kernel devs go? How far will companies go?
      • by MartinG ( 52587 ) on Tuesday January 30, 2007 @08:57AM (#17812814) Homepage Journal

        b) binary blob kernel patch created by hardware munfacturuers

        Widely believed to be a license violation.

        c) binary blob in kernel tree created under NDA by the kernel team (who have private access to the source)

        Almost certainly a license violation. (Can't be distributed with the portions of the kernel written by others who have released their code as GPL)

        d) obfuscated code in the kernel tree (with original kept private to those kernel devs that have signed the NDA)

        Probably a license violation (google for "gpl perferred form obfuscate")

        e) uncommented code in the kernel tree (with commented code kept private to those kernel devs that have signed the NDA)

        Dubious to keep commented version seperate for the same "preferred form" reason as above.

        IANAL.
      • I agree with your ranking, as long as you _know_ which one you're getting. I check for Linux compatibility before buying (most) hardware, but that doesn't tell the whole story. There is a legitimate fear of anything besides truly open source drivers. Anything less and not only is there a good chance it will break when new versions of the kernel are released, but also you're running code _in kernel mode_ that few, if any, people have audited for security and other problems. I prefer not having the device (or
    • One has to assume that the confidentiality pertains to the proprietary code interacting with the driver, not the driver code itself.
    • Re: (Score:3, Interesting)

      by gatzke ( 2977 )

      I think there are cases where there may be a lot of extra functionality in some hardware (for testing or legal versions). Maybe it can operate in bands limited by the FCC, but should not for legal reasons. The detailed docs covered by NDA may detail this, and there is no reason to put all the details in the open source driver to get something working.

      This way, you get your working open source driver, but you don't need all the details of the hardware (which may include a lot of IP for the hardware maker).
    • The announcement claims that the driver will be "automatically included in all Linux distributions". There is no way that is going to happen if the driver is binary, or even if it is obfuscated.

      So I can't see how they can support NDA.
    • by hal2814 ( 725639 )
      A way I can think of is to create partial source drivers. What I mean by that is to code up to the trade secrets and then leave those secrets in their binary form. It would still be more open that what we have today but I can see the argument against this idea since the Kernel devs would be working on drivers that are not completely open source.
  • All that is needed is some kind of specification that describes how your device works, or the email address of an engineer that is willing to answer questions every once in a while

    That's all they have to do now, basically - any modestly popular piece of hardware will probably get a driver if specs are available. But that's the same big "if" that has always been a problem.
  • A similar offer (Score:3, Informative)

    by mogrify ( 828588 ) on Tuesday January 30, 2007 @08:30AM (#17812602) Homepage

    The folks at Xiph have had a similar offer [xiph.org] for a few years:

    We've got a fixed-point implementation of the Ogg Vorbis 1.0 decoder, called Tremor. As of this evening, Tremor is licensed under a BSD-style license, is free for all use, and you can download it right here [xiph.org]. If you need help implementing Vorbis support into your hardware player, we will give you any resources at our disposal to make it happen (including engineer time). If you want Vorbis in your player (like your potential customers do), we want to help you.

    I don't know if anyone ever took them up on it. Ogg support in portable hardware has come a long way since then. I used to come back to this page every couple of weeks to see if anything had changed. Now a lot of players have it... I hope this takes off.

  • How long till a EE undergrad sends them a breadboard project and tells them "U write me da driver, u promise!"
  • Driver Management (Score:5, Interesting)

    by jone1941 ( 516270 ) <jone1941@g[ ]l.com ['mai' in gap]> on Tuesday January 30, 2007 @08:43AM (#17812690)
    The arguments about out of the box driver support for linux happen all the time. The reality is that the issue is not out of the box support. I often have more functionality out of the box with a modern linux distro than windows on the same hardware but that only gets me so far. The biggest hurdle is supporting less common hardware. Adding driver support in the kernel is great, but there is no way they can keep pace with the release of new obscure hardware. We need a way to support less common hardware without constantly trying to bundle drivers into the kernel. Also the kernel developers are not always willing to merge 3rd party code into the kernel if it isn't to their standards or is perhaps not 100% complete. I completely understand this process, but it doesn't help people who have to search out these drivers and try to compile them from source.

    The best example I have is my webcam. I know that when I purchased it it would have linux support because i did my research, but I still had to know how to do the research, how to track down the right driver and then how to build it from source. What we need is a driver manager that operates similarly to or in conjunction with our package managers. If during install or after a first boot I was told that a driver for my webcam was not installed as part of the distro it could then either download a driver package if one is available or it could at least suggest a link to download a driver not yet being packaged for my distro. Having to check my dmesg to see if my webcam shows up as a generic USB device or if a driver has been assigned to it is a terrible solution, we need a more friendly means of checking a supported devices database and better way to get access to the drivers that support our less common hardware. This is especially important for people who don't hand pick their hardware and are less familiar with exact model numbers or sometimes know even less.

    This system that manages drivers might also do well to phone home to the distro maintainer when possible to catalog all of the hardware that is not being supported by a driver. That way we can at least get a better idea of where the biggest holes in device support are.

  • I thought the purpose of the NDA was to stop people from figuring out how the hardware works.. how will they do that if I can see the source of the driver?

    I assume that the reason why most companies won't do open source drivers is because they want to cripple the hardware from the driver, to speculate or do stuff like DRM and things like that..

  • by mollymoo ( 202721 ) on Tuesday January 30, 2007 @09:01AM (#17812864) Journal

    Who is he speaking for? The whole Linux kernel community? I didn't think it worked that way. Even Linus is as much a cat herder as a boss, once you get beyond a few core people. The population of kernel developers who can be ordered (the difference between "might get a driver" and "will get a driver") to write drivers for obscure hardware they have no interest in must surely be fairly small. Who's actually in on this? Are there a few hundred kernel devs who've agreed to work on whatever they are assigned? I'm worried that this will backfire when they can't actually find anybody who wants to write the driver for a engraving machine that sells 400 units per year and has a particularly baroque interface. I don't expect there will be a problem for WiFi, TV or video cards, but there's a whole lot of hardware out there and not all of it is interesting.

    Those are some pretty big promises he's making. I'm wondering what's there to back them up.


  • you can add 'supported on Linux' to your product's marketing material.


    Writing a driver is one thing, but providing support is another.
    As far as I can see, there is nothing new here. People were always
    willing to write drivers for Linux & provide it free. Many a times
    they did it even without help from the manufacturing. So I don't
    see what exactly this announcement offers the manufacturers?

    I don't see manufacturers willing to stamp "supported on Linux"
    on their boxes just because the community made an offic
  • Put it next to the Intel Inside! or Powered by AMD:

    'Has been reported to work on Linux!'

If all else fails, lower your standards.

Working...