Free Linux Kernel Driver Development FAQ
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."
This makes an awful lot of sense. Currently, a lot of hardware gets drivers but without the assistance of the companies. This way, consumers benefit (if you can call us basement-bound linuxers consumers) and the companies benefit by reaching more people.
Can users sign up for this? I've got some hardware I'd love Linux to support. :p
Point your hardware vendor to the web site and ask them to participate. If you mean will someone reverse engineer your hardware, well they answer that question on the site FAQ and the answer is no.
Got Code?
"We'll write free drivers for your hardware if only you release the specification" - isn't this the same that was always done in Linux kernel? Or is the issue only about signing the NDA to get the specs?
From the FAQ
Q: This is a lame publicity stunt, Linux development has always been done this way.
A: Well, the NDA program that we have set up with The Linux Foundation is new. But yes, other than that, this is exactly how Linux kernel development has been done. But it is good to point out exactly how it all works for those who are not familiar with how it works.
BBH
Yes, this is not a lot different than the way device drivers have always been incorporated into the kernel. But having a willingness to work with NDAs of various companies MIGHT have solved the whole fiasco with Broadcom wireless chipsets (if you didn't think it was a fiasco, you didn't buy a iBook G4 the day they were released, May 2004, only to find out that you would be unable to use wireless on it for the next 2 years at least).
I don't know but I think that maybe such a system might have made the suits and lawyers with Broadcom comfortable enough to allow co-operation on a linux device driver... *sigh* would have been nice.
somewhere, on a Big Red Sign:
if(color==blue){speed--;}
Unfortunately a lot of companies seem totally unable to see the benefits of external contributors. They don't even see the point in getting drivers into the mainline kernel. Just take a look at this response from Cirrus Logic regarding their ep93xx boards:
- 2007/msg00026.html/
/C.M
http://www.freelists.org/archives/linux-cirrus/02
Looks like the in house coding team was bummed that Lennert Buytenhek did a better job on the port then their whole team. Ridiculous response!
/C.M
Most of the online guides for the few bits of hardware that do exactly what you suggest tell you to ignore the drivers the hardware comes with, as a newer kernel will almost certainly be out by now with an updated driver. The last thing we should do is try to get them to supply the drivers with the hardware.
What we want - and what this process does - is to get them to release enough information that a driver can be written and incorporated upstream into the kernel so that Linux supports their hardware out-of-the-box. This bypasses all the "critical mass" problems because they don't have to pay for the development costs, and negates the need to supply drivers with the hardware. How can they lose?
So.. it has come to this
You may also be able to get some short-term work from companies wanting to switch existing infrastructure to Linux and needing drivers for existing hardware, although this is likely to be contingent on your acquiring the device specs first.
I am TheRaven on Soylent News
For starters, the norm to starting this process is that the hardware is out and somebody has an itch. Then they have to go to the hassle of getting the manufacturers specs, etc.
Now, some manufacturer will be approaching the kernel team and offering the specs. The kernel team will probably pick an active developer who wishes to do it. Interestingly, manufacturers will be more likely to bring in alpha (or beta) hardware to have the drivers built BEFORE going to market. Once they figure out the sales potential from Linux, then they will be more likely to develop the drivers in-house.
I prefer the "u" in honour as it seems to be missing these days.
Yes, but... Who told the hardware vendors about that? :-p
Someone finally did, explained the benefits, and got an amazing number of responses :-)
We take much for granted. When you meet a Linux newbie you'll notice how much "hidden knowledge" we have. Who the community is, that the FSF / GPL is, how the OS is layered in tools and front ends, what "compiling" does, how communication is done, how to find answers for problems. Linux newbies are not aware of this. The same can be said about hardware vendors.
Even if a vendor jumped in a random channel, the average response is "Open Source it". We understand the meaning and advantages of that approach. They only think "help, I must give away my code". It was about time someone stepped up to shed some light on these matters.
The best way to accelerate a windows server is by 9.81 m/s2
heard of the GPL? http://www.gnu.org/copyleft/gpl.html
"Stallman says add to this code and you are one of us. Gates says use this code and you belong to us."
You're kidding yourself - I have used, and continue to use - a number of closed source binary Linux device drivers acquired from 3rd party manufacturers. The real reasons you don't see Linux device drivers shipping with hardware are:
It's worth noting that in many cases Microsoft produces or buys drivers for hardware. thereby obviating the [percieved] need for the manufacturer to spend much effort on any OS drivers, let alone one as arcane as a *nix driver with some hippie "licensing" scheme...
Also, if a device is designed to an existing h/w spec utilitized by M$, again - no driver needs to be produced by the h/w manufacturer.
It's all about margins, market share, ignorance, and prejudice. The relative openness of the Linux systems has nothing to do with it, nor does your imagined inability of Systems other than "Solaris and Windows" to dynamically link a loaded binary module. Futhermore, I am unaware of any consumer-grade h/w device which has Solaris OS driver support, which does not also have support under Linux.
The fact that you and/or your shop have never so much as looked at the Linux OS to a degree sufficient to producing a device driver for it is obvious from your posting, so please: Sit down, and STFU until such time as you have poked around a bit and actually know someting about what you're talking about - you've forced me to waste an unacceptable amount of bitwidth trying to clear the smoke you've blowing in front of the mirrors...
"The Internet is made of cats."
It'd be funnier if an unmeasurable number of new Linux drivers were created. "An infinite number of Linux drivers were created this week."
If only we had an infinite number of monkeys...
(Gotta love preview. I just noticed the original article is on the Linux Kernel Monkey Log. Maybe we DO have more monkeys than I realize.)
Learning HOW to think is more important than learning WHAT to think.
I think the real point in those situations is "if it goes wrong I can put the blame on a big company the PHB has heard of, otherwise it will be my fault".
Guess what. Odds are, it'll still be your fault. Your fault for not getting the specs right. Your fault for not working with the major vendor to make it work. After all, they're a big company and have hundreds if not thousands of other installations working right. Thus, if they all work and yours doesn't -- it is your fault.
The ONLY way you might get away with that is if some executive MANDATED you use a specific product, overriding your objections or advise to the contrary, and he is a known asshole in the company. Even then, it is still iffy.
And finally, even if it isn't your fault and you can successfully blame someone else, you'll still get a bit of a reputation of "that guy who couldn't get it done".
Good luck!
Learning HOW to think is more important than learning WHAT to think.