Slashdot Log In
Linux Kernel Devs Offer Free Driver Development
Posted by
kdawson
on Tue Jan 30, 2007 08:41 AM
from the Nvidia-this-means-you dept.
from the Nvidia-this-means-you dept.
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."
Related Stories
[+]
Free Linux Kernel Driver Development FAQ 84 comments
schwaang writes "The recent announcement by Linux Kernel Developer Greg Kroah-Hartman that 'the Linux kernel community is offering all companies free Linux driver development' seems to have stirred up some interest as well as some questions — see the Slashdot discussion about the announcement. Greg K-H addresses some of the questions raised here, and raises a few more, in a new Free Linux Driver Development FAQ on his blog. An excerpt: 'Q: Are companies really going to do this? A: Yes, already we have received a number of serious queries from companies about producing Linux drivers for their devices. More information will be available later when details are firmed up."
[+]
News: Update On Free Linux Driver Development 272 comments
Remember the offer Greg Kroah-Hartman made earlier this year, to get Linux drivers written for free for any company that wanted them? Now an anonymous reader points us to an article up on linuxworld with an update to this program. Greg K-H, who leads the development of several kernel subsystems including USB and PCI, admits that the January offer was a bit of "marketing hype" — but says it has brought companies and developers together anyway. Twelve companies have said "yes please," one driver is already in the kernel, and five more are in the pipeline.
[+]
Know Any Hardware Needing Better Linux Support? 518 comments
Dev Null writes "The Linux device driver project has hit something of a snag: they have lots of developers, but few devices to work on, so they're looking for input concerning which devices aren't well-supported in Linux. If any of you know of devices that could use better support, you can help out by listing them on the project's wiki."
[+]
Linux Supports More Devices Than Any Other OS 272 comments
Linux Blog recommends an interview up on the O'Reilly site with Greg Kroah-Hartman, long-time Linux kernel hacker and the current Linux kernel maintainer for the USB driver core. He updates the free Linux driver program announced almost two years ago, which has really caught traction now with more than 300 developers volunteering. The interviewer begins by asking about Kroah-Hartman's claim that the Linux kernel now supports more devices than any other operating system ever has. "[One factor is] the ease of writing drivers; Linux drivers are at normally one-third smaller than Windows drivers or other operating system drivers. We have all the examples there, so it's trivial to write a new one if you have new hardware, usually because you can copy the code and go. We maintain them... forever, so the old ones don't disappear and we run on every single processor out there. I mean Linux is 80% of the world's top 500 super computers right now and we're also the number one embedded operating system today. We've got both sides of the market because it's — yeah it's pretty amazing. I don't know why, but we're doing something right."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
How many (Score:5, Insightful)
Re:How many (Score:5, Interesting)
Parent
Re:How many (Score:5, Interesting)
Parent
Re:How many (Score:5, Insightful)
Companies worried about IP issues should ask themselves if they are in the hardware business or the software business. If their objective is to sell more gizzmos, then opening the API to developers is an excellent way to sell more product.
If a company is concerned about the number of questions they'll be asked by the developers, then (a) they don't know the software business, and (b) they should take a long, hard look at the quality of their documentation.
The biggest problem is that many companies are already making so much from selling their gizzmos to Windows users not to need to sell them to Mac or Linux users as well, even though it takes no significant effort to do so. The extra profit, even at virtually 100% per unit) simply isn't attractive.
Parent
seems like a good idea (Score:5, Insightful)
Re:seems like a good idea (Score:5, Interesting)
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.
Parent
Re:seems like a good idea (Score:5, Insightful)
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.
Parent
Re:seems like a good idea (Score:5, Interesting)
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...).
Parent
Re:seems like a good idea (Score:5, Insightful)
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.
Parent
Re:seems like a good idea (Score:5, Insightful)
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.
Parent
Hardware ? (Score:5, Insightful)
Re:Hardware ? (Score:5, Informative)
Parent
Dedicated (Score:5, Insightful)
Peter
This is needed (Score:5, Insightful)
Wonderful (Score:5, Interesting)
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)
Parent
Re:Wonderful (Score:5, Insightful)
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?
Parent
Standard Driver Model? (Score:5, Interesting)
Re:Standard Driver Model? (Score:5, Informative)
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.
Parent
How will the NDA work ? (Score:5, Insightful)
Re:How will the NDA work ? (Score:5, Interesting)
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?
Parent
Re:How will the NDA work ? (Score:5, Informative)
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.
Parent
Driver Management (Score:5, Interesting)
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.
This is definitley new (Score:5, Insightful)
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.
Parent
Example of extending to other platform (Score:5, Informative)
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).
Parent