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."

Comments

Sweet

[Stormx2]

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.

Re:Sweet

[Anonymous Coward]

if you can call us basement-bound linuxers consumers

I know for sure I'd be much more likely to buy good new brand hardware if I knew it would Just Work with Linux.

Right now I only grab the older stuff I need from ebay (used) or other stores.

Re:Sweet

[Jekler]

Linux users are definitely consumers. Believing that having the basic functionality of operating your computer for free isn't about exiting the market as a consumer. It's along the lines of how you should be able to operate your television for free. You don't need cable, satellite, or any product separate from the equipment itself for your TV to function. You can buy a TV, watch DVDs, tapes, home videos, set it up as a security monitor, or use it just as speakers for an audio tape player, whatever you want to do with it.

Up until Linux, if you bought computer hardware, it was a dead box unless you also paid for an operating system, of which the only real choice was Windows. You couldn't use the hardware you had bought. You had a computer that couldn't compute anything. No matter how small your needs were, even if the only thing you ever needed to do was create plain text files, you had to pay $90+. With Windows XP Professional, it should burn any purchasing manager to think about paying $300 for a pinball game and another half dozen games, movie maker, media player, and various libraries and functions to support those applications, when the reason the computer is needed may not ever involve any of those. Whether or not those applications are needed you must pay for them. Enter Linux.

It's a misnomer that Linux users are cheapskates. Linux users will pay just as much cold, hard cash as the next guy for applications and products that fill his needs, they're just not willing to pay for peripheral garbage that has no value to them. As a Linux user, I've personally paid $4500 for an IDE/toolkit.

There are many Linux users who want to be consumers, and would gladly pay for things like 3D Studio Max, Photoshop CS2, etc. but those things aren't being offered to Linux users. Linux users are consumers lacking producers. We might have money but, for some reason, a lot of companies don't think a Linux user's money spends like the other kind, which is a shame because companies like Google have a lot of Linux money to throw around.

Basement-bound Linux users are no different, eventually they become purchasing managers, company owners, or hobbyists who build up some cash and want to spend it on something. If someone makes a decent offer, they'll fork over the cash just like anyone else.

Re:Sweet

[Stormx2]

Well I agree, to tell you the truth. I wasn't trying to be confrontational, and what you say about us being consumers is completely correct.

More, its the general market for software which is stuck in the same old ways. Generally speaking, something thats free is lesser quality than something that costs. In the normal product world, you might go out looking for an oven. Companies sell them so they can make a certain profit, while making the price attractive to a consumer. The consumers know that, so a more expensive oven means a better oven. Usually.

The advent of the internet and alternative business models means this doesn't have to be the case, yet those who live their lives in shopping malls and highstreets woudln't know it. I've had a few fun times trying to explain to friends why something so good can be free, and not illegal. I'm under the impression that businesses, in trying to visualise what consumers want, stay as narrow minded as them. Hence they make the assumption that free software lovers are not not consumers, just very lousy and cheap consumers.

I don't want things to be this way, of course. I (with a little help) built the PC I'm typing this with, and tend to use linux maybe 80% of the time (20% on windows for graphics work).

My previous post was based off the stereotype more than anything else.

Can users sign up for this?

[Excelcia]

Can users sign up for this? I've got some hardware I'd love Linux to support. :p

Re:Can users sign up for this?

[WindBourne]

If you have the original specs and can answer some questions about the hardware, then sure.

Somebody pleasexplain what this all is about

[gsasha]

"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?

Re:Somebody pleasexplain what this all is about

[BigBuckHunter]

"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

Re:Somebody please explain what this all is about

[Excelcia]

You and I both should have read the FAQ before posting. ;)

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. (emphasis added)

No company-oriented questions?

[Anonymous Coward]

Interestingly, all the frequently asked questions were asked by random linux users and developers. It seems that device manufacturing companies aren't making any frequent questions at all!

Sure you can

[codepunk]

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.

Re:Sure you can

[i.r.id10t]

FAQ is wrong then. Correct answer is "maybe. is there anyone out there with the skills to do it and desparate enough to use your particular bit of kit to do it?"

Re:Sure you can

[drinkypoo]

FAQ is wrong then. Correct answer is "maybe. is there anyone out there with the skills to do it and desparate enough to use your particular bit of kit to do it?"

I think you done missed the point completely, son. The FAQ is 100% correct. The people involved with THIS project will not be reverse-engineering anything as part of this project, whose point is more or less the converse of this desire.

Re:Sure you can

[Knuckles]

No, the correct answer is that Greg Kroah-Hartman's effort won't do it. Anyone else, sure, maybe, but that's not what the FAQ is about.

Zero

[Mr. Underbridge]

A: Yes, the initial response to this was amazing, a measurable number of new Linux drivers will be created thanks to this program.

As per a Simpson's episode, I'm reminded that zero is a number. ;)

Re:Zero

[AJWM]

I'm reminded that zero is a number.

Well yes, but arguably not a measurable one. ;-)

Re:Zero

[Anonymous Coward]

"I'm reminded that zero is a number."

Well yes, but arguably not a measurable one. ;-)

Huh? Zero is no less measurable than any other number.

Re:Zero

[srussell]

A: Yes, the initial response to this was amazing, a measurable number of new Linux drivers will be created thanks to this program.

As per a Simpson's episode, I'm reminded that zero is a number. ;)

It'd be funnier if an unmeasurable number of new Linux drivers were created.

"An infinite number of Linux drivers were created this week."

--- SER

Re:Zero

[chill]

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.)

Re:Zero

[bnenning]

"An infinite number of Linux drivers were created this week."

That's easy:
#!/usr/bin/perl
sub createDriver {
    $h = sprintf "%lx",$_[0];
    $h = "0$h" if (length($h)%2!=0);
    open(D, ">$_[0].driver");
    for($i=0; $i<length($h)/2; $i++) {
            printf D "%c",hex(substr($h,$i*2,2));
    }
}
$d = 0;
while(1) {createDriver($d++);}

(Determining which output files are useful Linux drivers is left as an exercise for the reader).

Re:Zero

[dubbreak]

If only we had an infinite number of monkeys...

No, no, no.. that's how MS does it's driver development.

Re:How is this news?

[xtracto]

by EveryNickIsTaken (1054794) Alter Relationship
Is it really that shocking that hardware manufacturers are interested in having drivers developed for free that would enable them to reach additional consumers?

Oh.. wait. It's Linux. So that means it's news. Yeah, right.

1. You must be new here.

2. As stated in the FFAQ:
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.

The main idea is to let companies know that it is possible to release hardware specifications in an NDA-esque way to kernel developers *without* having to publish their /precious/ secrets. Chances are that, the secrets are not *within the code* but developers need to know about them to implement the drivers.

how do these developers get paid?

[Anonymous Coward]

Just wondering, how do these developers get paid? I would love to develop kernel drivers, and I can, but it takes a lot of time, which I need to make money, so how do these "free developers" do that?

Re:how do these developers get paid?

[diegocgteleline.es]

Just wondering, how do these developers get paid?

They don't. Or the contrary. The whole "kernel community" is supposed to help to get those drivers, who knows if some of those people will be paid or not. I think that everybody, paid or not, should help to finish this project succesfully.

Re:how do these developers get paid?

[TheRaven64]

Many of them are paid by distributions. Novell and RedHat, for example, make money buy selling support for Linux. The more hardware their distribution supports, the easier it is to sell. Getting good drivers in the upstream tree is the easiest way of doing this, so they pay kernel developers. If you are able to write kernel code and interested in doing it for a living, I would suggest you send your CV off to the big distros (and possibly IBM) and ask if they have any openings.

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.

Re:how do these developers get paid?

[Anonymous Coward]

Write a driver in your own time, get it committed and then approach distributors and hardware companies. Nobody employs people at that level based on what they say they can do. The proof is in the pudding or the driver code or something.

Re:how do these developers get paid?

[oliverthered]

First you have to show your intentions and your skills, write a few drivers and try to get them into the kernel tree.

Then you have to try and find yourself a job where they let you do kernel development, if your good enough then all you have to do is shout for a new job and someone will pick you up.

Unless your really good and dedicated your going to have a hard time getting paid for developing kernel drivers.

Re:how do these developers get paid?

[Anonymous Coward]

Most of them don't. Mommy comes down into the basement and brings them turkey sandwiches and cheetos.

Re:how do these developers get paid?

[schwaang]

Just like with the rest of the Open Source community, there are a mix of motives and situations. I'm not a kernel developer, but as an observer of FOSS generally:

Some are paid to work on Linux as employees of Linux distros like Red Hat or Novel, or work for hardware or system vendors who want their products to work with Linux (HP, Intel, Dell, etc.).

Some are in job positions in corporations where they use Linux, and need/want a particular piece of third-party hardware to work for their application (be it a financial database or what have you).

Some are in academia and have the time to "publish" open source.

Some are just enthusiasts or experts or learners in a particular domain, and enjoy the challenge and notoriety they get. Some leverage that unpaid notoriety in order to get paying jobs. (FOSS credentials are portable.)

And yeah, some just get cheetos brought down to the basement by mom. ;)

What we really need

[gavink42]

What we really need is for companies to provide Linux drivers on their own, and delivered with their hardware. I've wondered for years why most of them don't do that.

It's also a "critical mass" sort of thing. Once all hardware companies provide full support for Linux, then Linux will be in a position to truly be a mainstream replacement for Windows.

I'm sure their reasons have to do with perceived user base. But, how do we get them to support us without that "critical mass" of users? It's like the chicken and egg thing, and very frustrating!

Re:What we really need

[oneandoneis2]

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?

Re:What we really need

[Anonymous Coward]

> The last thing we should do is try to get them to supply the drivers with the hardware.

Yeah, it's a much more scalable solution for the kernel to continue to include every single driver for every single piece of hardware in existence.

Re:What we really need

[isorox]

Yeah, it's a much more scalable solution for the kernel to continue to include every single driver for every single piece of hardware in existence.

Distrbutions decide which drivers to include as default, however yes, the idea is that the kernel supports your hardware, no matter what it is.

Re:What we really need

[SpeedBump0619]

What we really need is for companies to provide Linux drivers on their own, and delivered with their hardware. I've wondered for years why most of them don't do that.

It is expensive to create hardware. If you publish your hardware register set, internal bus mappings, and the meanings of all the magic numbers so prevalent in hardware level code, it makes it easier (and cheaper) to reverse engineer hardware. Most companies that do real hardware development spend a lot of money up front doing design and prototyping, and expect to make that money back in sales over the lifetime of the product. By releasing the code for the driver reverse engineering has become cheaper. The life of most products these days is less than two years. If we lose six months of that to knockoffs designed to exactly mimic our hardware we land firmly in the red.

Windows and Solaris provide a binary kernel API so that compiled code can be loaded. We can release drivers without giving away the keys to the hardware. Linux explicitly doesn't allow that. With Linux it is all or nothing, and many hardware manufacturers choose the predictable 'nothing' instead of the less predictable 'all'.

Re:What we really need

[Zantetsuken]

thats what modules are for - they don't actually get compiled in, and allow for a - well, more modular way of including drivers. use the distro's update/install mechanism "apt-get/yum/yast/etc kmod-some_odd_driver"

Re:What we really need

[Skapare]

When the driver is provided with the hardware, they also need to provide instructions on how to make that driver work on any given Linux system, or at least some popular distribution. In addition to that, they will need to provide some level of support, at least for the installation process. Linux's distribution-fracture nature makes that harder so many companies pick one distribution (hint: it isn't Debian, Gentoo, or Slackware).

Ideally, we should get the drivers into the distributed kernel tree as soon as possible so distributions can include it automatically in new versions. Then only those who drag their feet on upgrading need to do a driver install themselves.

One complication for many companies is that they don't want the product to be known to exist until the official release date, even if they have no issue with releasing the driver source and even the specs documents. Many don't mind releasing source, but might want the specs documents to stay closed (which doesn't really seem to conflict with GPL). So one idea is for developers to sign time constrained NDA's the restrict the disclosure of the existance of the device until the official release date. This way, Linux driver development can be ongoing behind the scenes and the driver source can be submitted to the kernel tree on the product release date, as well as drivers included in with the hard or on the manufacturer's web site for geeks living on the edge.

This gets us more supported devices, both directly and indirectly. The indirectly comes from manufacturers that would otherwise resist open source drivers being forced into it by their competition moving ahead with open source drivers because we make it a bit easier for them to do so (under the dated release constraints).

I don't personally have a goal of replacing Windows with Linux in the perspective of the whole market. For my own needs, Linux replaced Windows a long time ago. My goals are selfish: I want more drivers and applications on Linux that I can use. It is the commercial interest of developing only for larger markets that require that we have a larger Linux user base for them to proceed with that.

Re:What we really need

[0x0000]

Linux explicitly doesn't allow that. With Linux it is all or nothing, and many hardware manufacturers choose the predictable 'nothing' instead of the less predictable 'all'.

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:

1. The manufacturers typically lack the software skills to create a linux device driver in-house, and don't feel that sales to Linux users will comprise sufficient dollar amount sales to justify paying a developer to create one.
2. Plain Old Ingnorance (POI) due to not having anyone in a position of influence at the company with sufficient knowledge of things like GPL licensing and non-Windows systems to know just how full of shit remarks like the one you make above really are.
3. All the usual hate, religion, and bribery that are brought into play when anyone in the industry so much as thinks about doing something that is not Windows.

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...

Re:What we really need

[Knuckles]

What we really need is for companies to provide Linux drivers on their own, and delivered with their hardware

No we don't. It's much simpler for users if the drivers are in the kernel. I don't need Windows driver hell recreated in Linux.

I've wondered for years why most of them don't do that.

The kernel ABI is not stable, so the drivers (or at least some glue layer) would need to be recompiled

Re:What we really need

[iabervon]

A lot of companies don't have the skill set to produce high-quality maintainable drivers. Not that they're bad engineers, but they put more effort into hardware design, and whatever functionality the device has. This makes sense; I'd much rather have a device that follows the PCI spec correctly than one where the vendor knows how to work around the quirks in the driver.

The best devices are ones that use non-vendor-specific drivers. For example, disk controllers are increasingly "AHCI", and, so long as they behave as specified, they don't need new drivers at all, because the ahci driver handles all of them without any vendor-specific input. I've got an SD card reader in my laptop from a vendor that doesn't have any Linux relationship at all, but the hardware works fine because it follows a published spec. Likewise, USB storage devices. "HDA" sound devices get partway there (the device behaves in a standard way, but then you need drivers for the codec, which is extra exciting because it's a chip from yet another vendor; I've got a Lenovo laptop with an Intel sound card, with two codecs: an Analog Devices one, and a Cirrus (I think) one; it's unclear who'd provide the necessary software to the end user here, but ALSA handles it all fine, afaict).

Of course, half of the knowledge needed to write a good Linux driver is about Linux, rather than about the hardware, and not understanding the Linux side is more likely to cause system instability and problems that aren't easy to identify.

What I'd like vendors to do, as far as Linux support in the device box, is list the mainline kernel driver options you need and the names of the modules you'll get, and the kernel version you need in order to have the driver (and have it know about the device).

Re:What we really need

[mrchaotica]

Yeah, it's a much more scalable solution for the kernel to continue to include every single driver for every single piece of hardware in existence.

Yes, it is more scalable that way! You know why? Because a big chunk of what kernel developers do is re-organize the code to create better abstractions and reduce duplication. If every bit of hardware had it's own separate driver you'd have a huge mess (like on Windows) as opposed to the managed mess we have now.

Besides, the only really scalable solution would be for hardware makers to design to a standard (e.g. make their hardware act like a generic device of type foo), so that all devices of the same kind can use the same driver.

Re:What we really need

[schwaang]

Windows and Solaris provide a binary kernel API so that compiled code can be loaded. We can release drivers without giving away the keys to the hardware. Linux explicitly doesn't allow that. With Linux it is all or nothing, and many hardware manufacturers choose the predictable 'nothing' instead of the less predictable 'all'.

It probably is true that the Linux kernel's intentional lack of ABI compatibility has been a hurdle for some vendors who would otherwise produce a proprietary kernel driver for their hardware. It hasn't stopped nvidia from doing that, and it hasn't stopped that company that sells winmodem drivers, among others.

But really, closed-source drivers are bad for so many reasons that pretty much everyone here already knows about (unmaintainable, un-redistributable, can't be reviewed for security or other trust issues, can't be improved upon). Plus Linux has been able to grow very rapidly, and an ABI-compatibility constraint would have hampered that. So enabling closed-source drivers is a big lose on many fronts.

Sure there are going to be a few vendors who feel they absolutely cannot open their drivers and cannot open their hardware specs enough to let the community produce an open driver. There are several different reasons a company might take this position, some more valid than others (given that binary drivers can be disassembled by a competing vendor anyway).

My bet is that as these vendors see other companies having a good working relationship with the kernel community, more of them will see that the benefits of opening (shifting some development/support/maintenance/liability costs outside of their own budgets, having access to the increasing Linux market) outweigh the benefits of keeping their specs closed.

So anything Greg K-H & other kernel devs & the OSDL/Linux Foundation do to reach out to these vendors and provide a process that they can understand and trust deserves kudos, IMHO.

Re:What we really need

[juhaz]

That's absolutely the worst thing that can possibly happen.

Windows is pretty stable in theory and on it's own. It's not stable in practice. Why?
Because companies provide drivers on their own and delivered with their hardware. Drivers that suck. Drivers that are unstable pieces of crap. Drivers that take the OS down with them.

It's also a "critical mass" sort of thing. Once all hardware companies provide full support for Linux, then Linux will be in a position to truly be a mainstream replacement for Windows.

Once all hardware companies provide the same kind of "support" for Linux, Linux won't have to replace windows, Linux will BE Windows.

Re:What we really need

[SpeedBump0619]

I thought I'd let you know that I have in fact written (well, helped to write) the Linux driver for a number of video capture devices (supporting the Osprey 200, 210, 220, 500, and 540). At the time when I was involved in this work (2000-2003) there were a number of consumer devices supported by Solaris but not Linux. It isn't about ignorance or at least it wasn't with Viewcast, it was about protecting our investment. During my time with them we had two instances of knock-offs produced by companies in China.

It is too bad that you assume I'm full of it. I no longer write Linux drivers, but that doesn't invalidate my *experience* with a hardware manufacurer. Zealotry is one of the things that scares business away, and you just contributed.

Good Day.

Re:What we really need

[0x0000]

Yeah - right - and your bringing up non-sensical, unrelated arguments from your own sordid past why? No one cares - none of tha addresses the point, and none of it says anything about why any company may or may not produce a Linux driver...

Zealotry is one of the things that scares business away, and you just contributed.

Fuck you - you're a stupid twit, and stupid twits drive away a lot more business than zealots do - you nned to breathe deep and take a look at the Big Picture, for a change - sounds like you've been stuck in some dusty closet at the "Solaris Experts" department of Microsoft, or something - come on, can you be any more pathetic? Someone around here might be interested ... probably not me, but ... well, you never know, do you.

Re:What we really need

[SpeedBump0619]

...non-sensical, unrelated arguments...

The OP "wondered for years why most [companies] don't [provide Linux drivers]". How, exactly is an explanation of why one specific company was reluctant to do so "non-sensical or unrelated"? I'm sorry if you don't grok the point of view, but that doesn't make it irrelevant.

The manufacturers typically lack the software skills to create a linux device driver in-house

Unless things have changed noticably in the last 4 years, Linux is the easiest system I know of to write drivers for, specifically *because* it is open source. Don't know how to do something? just look at the driver for device X and see how they did it. Anyone who can write a WDM driver can write drivers for Linux. The hard part about writing drivers isn't the system API its the hardware. The APIs are all the same: Message enters saying "do this and give me a result", you block while performing the request and return a response, unless you are non-blocking, then you record some stuff for later instead of blocking. It isn't rocket science.

and don't feel that sales to Linux users will comprise sufficient dollar amount sales to justify paying a developer to create one.

That is a reasonable argument and is a legitimite concern for hardware that is tightly coupled with user space applications. The spread of virtualization is making this a less prevalent concern.

Plain Old Ingnorance (POI) due to not having anyone in a position of influence at the company with sufficient knowledge of things like GPL licensing and non-Windows systems to know just how full of shit remarks like the one you make above really are.

It is fantastic that you think the GPL is so simple to understand...perhaps you could settle the question of whether creating a binary blob driver is actually legal or not. It seems that every time I try to get a straight answer on this a shouting match starts between the two camps: "The code that implements the API is GPL'd so anything using the API must be GPL'd", and "The code that implements the API is GPL'd, but anything can use the API". I'm in the latter camp BTW, but I'm not a lawyer.

All the usual hate, religion, and bribery that are brought into play when anyone in the industry so much as thinks about doing something that is not Windows.

"the industry"? I'm apparently far enough outside of this that this just sound hysterical. There's no conspiracy. Microsoft wants businesses to continue supporting them, but there's no baptisms, rites of passage or crusades involved. It's just business: do what makes each company the most money. Businesses choose to support the market leader's stuff. Sometimes they see profit margins in supporting other niches in the market, and sometimes they don't. Your comment smells like a spurious relationship: linux isn't universally supported, Windows is, therefore there is a conspiracy to keep Linux down.

...like you've been stuck in some dusty closet at the "Solaris Experts" department of Microsoft...

Heh. I bet it pays pretty well, but no, today I work creating embedded control systems for automation systems. While I occationally am pulled back into the headaches inherent to portable driver level code I work closer to the iron now. This is strike two on the assumpt-o-meter (your first was assuming I'd never written a Linux kernel driver).

In the past I *have* driven business away from Open Source when it was the right thing to do. I have driven businesses toward Open Source when it was viable. My original point was an attempt to explain *why* some businesses might legitimitely avoid open source options, since the OP was not seeing their perspective. I, like many people, think the Free Kernel Driver Development Offer is just a PR stunt. That being

Re:What we really need

[0x0000]

Research please?

Grow up. Please? You are taking yourself - and apparenlty me - way too seriously. If you really, really truly think you know what you're talking about, and I don't guess what? Unless you can offer me some new information that might modify my opinion, I just don't give a crap - not even enough to try to convince you - far, far easier to just toss out some ad hominum tweaks, sit back, and laugh...

If you want the last word now's the time, I promise I won't respond again (well, not in this thread at least).

Well, I guess not, given what you said next...

but your argument was based on the assumption that open source is the One True Way,

Well, I guess this would HAVE TO BE your last response, since I freaking DEFY you to back that statement up using anything from any of my posts in this thread or any other - futhermore, I'll leave this contest open ended - you can email your response at any time to the email address listed for this account. I was almost interested in what you were posting - even with the stilted [humourless] styling - until I got to that...

and that all who didn't agree were either ignorant or deceitful.

Yeah - that old chestnut. You sound like my sister-in-law. Again, show me. Please. I will take back anything I ever said, award you cash prizes, etc etc if you can back that up to a jury of peers - or even just to me. You statement there is just pathetic beyond words...

By choosing this argument style you have made it difficult to attack your argument without attacking you.

Doh. You noticed that, did you? Perhaps you are a bit above average after all... My challenge stands. You picked the wrong weakness. You can do better. Or not. I'll check back tomorrow.

Could've solved broadcom

[g4sy]

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.

Re:Could've solved broadcom

[mrchaotica]

There's NDAs and then there's NDAs. The kind of NDAs this effort is willing to abide by are the kind saying "don't tell anybody the details of the hardware you're writing the driver for until after it's released." The kind of NDAs that Broadcom wants, but which are incompatible with all Free Software (including this) are the ones that say "you can't release specs EVER, so you will always be dependent on us to tell you how the hardware works (even after we've long since abandoned it)."

Cirrus Logic doesn't appreciate help

[ClaesMogren]

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:

http://www.freelists.org/archives/linux-cirrus/02- 2007/msg00026.html/

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

Re:Cirrus Logic doesn't appreciate help

[Intron]

Nobody in a position of authority at Cirrus is likely to have written that post. It is full of spelling and grammar errors. My guess is some low-level developer figured it was job security to try to get rid of the outside developer. Also, why don't links work on that page?

Re:Cirrus Logic doesn't appreciate help

[nietsch]

Man, that response was so uninformed, arrogant and dumb. I suspect some newbie manager type is now explaining to the PR department that his move really saved them a lot of money that was well worth losing face over. Right now the message reads: Cirrus products will not support Linux. There, let google lap it up. Lets hope for Lennert that someone higherup the chain will intervene, otherwise he will need to find a new subject to play with.

Re:Cirrus Logic doesn't appreciate help

[richlv]

remove the slash from the end of that link, it nicely messes things up

Re:Cirrus Logic doesn't appreciate help

[Anonymous Coward]

Take a look at the posts on their forum. These guys are totally clueless.

http://arm.cirrus.com/forum/viewtopic.php?t=183

Wow !!!

[__aahlyu4518]

A free FAQ !

Not entirely true either

[WindBourne]

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.

Re:How about Lirc?

[WindBourne]

Mine works fine. What card do you have that does not work?

liability?

[popeyethesailor]

How does the foundation handle liability issues? If a driver doesnt work as advertised, who gets the blame? What happens if a buggy driver fries the device in question?

Re:liability?

[fimbulvetr]

It's linux. There are huge disclaimers everywhere about libability, amongst other things.

This is a tough concept for windows boys to grasp because they come from the world of "If it doesn't work we call MS/Dell/HP" etc.

Besides, is oracle liable for your data loss when you lose your oracle instance? MS when you lose your IIS website?

Re:liability?

[Frequently_Asked_Ans]

11. because the program is licensed free of charge, there is no warranty for the program, to the extent permitted by applicable law. except when otherwise stated in writing the copyright holders and/or other parties provide the program "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. the entire risk as to the quality and performance of the program is with you. should the program prove defective, you assume the cost of all necessary servicing, repair or correction.

heard of the GPL? http://www.gnu.org/copyleft/gpl.html

Re:liability?

[the_womble]

Besides, is oracle liable for your data loss when you lose your oracle instance? MS when you lose your IIS website?

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".

Re:liability?

[fimbulvetr]

I rest my case, thanks for the followup.

Re:liability?

[chill]

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!

Re:liability?

[bensch128]

Besides, is oracle liable for your data loss when you lose your oracle instance? MS when you lose your IIS website?

No (because of the EULA) but they should be. Otherwise, why did you shell out the big bucks for Oracle or IIS? You might as well use apache.
Likewise, if you buy RHEL and apache falls over even after you installed it properly, Redhat should be liable.

but IANAL so this could be all pie in the sky when it comes to an actual lawsuit.

Cheers
Ben

RTFA actually has some meaning here

[jimicus]

The FA is an FAQ, FFS! Almost every question which has been brought up in the discussion is already in the FAQ because it's an FAQ, that's what it's for.

Yes it's always done like that mostly, but....

[vdboor]

isn't this the same that was always done in Linux kernel?

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.

Re:How is this news?

[cortana]

The main idea is to let companies know that it is possible to release hardware specifications in an NDA-esque way to kernel developers *without* having to publish their /precious/ secrets. Chances are that, the secrets are not *within the code* but developers need to know about them to implement the drivers.

The NDAs that Grek K-H talked about were of the kind that would keep details about the release of products secret until a specific date (e.g., product launch). I don't think he was talking about the kind of NDAs that maintain secrecy about hardware implementation details, etc. Such NDAs are harmful because they prevent the driver from being modified once the original maintainer dies, loses interest, etc. They should be rejected with prejudice.

How do they determine that?

[Anonymous Coward]

How do they figure out the sales potential for Linux? Unless you sell a different version for Windows and Linux, you'll never know how many sales were to Linux users versus Windows users. If you have a download for the driver on your site and get 2000 hits, you could get some idea, but it could be 100 customers who download every minor point revision and make it look like 2000 customers, or it could be 20,000 customers, only one of 10 whom download from your site versus getting it from their distro or another location.

Re:How do they determine that?

[WindBourne]

hmmm. Perhaps it is time to have the distros send out info about the systems that are configured. i.e. during the install, ask the admin if the object to certain info going out about the system (ala Windows). This could be done in the open and could use a number of serial numbers from the system so that unique systems can be determined. And privacy can be handled by not using macs or ip addresses.

Re:How do they determine that?

[theshowmecanuck]

The understanding I get is that this is so manufacturers can include the Linux drivers with the devices when they are purchased. After purchasing and installing most devices now-a-days the users generally have the option of registering their purchase with the manufacturer for warranty purposes (and which is probably also used by marketing types as well... which is good in this case). The manufacturers registration web pages often ask what operating system it is being used with... As long as Linux users made sure to register their purchase it would be a way to show the market potential.

I know that there will be many who will download to retroactively upgrade to manufacturers certified drivers. But you have to start somewhere. The initial downloads should be an indication of the potential market. The registration of new devices would be the ongoing part. Note that I actually don't like using 'should', 'would', 'could'... but this is all hypothetical BS'ing anyway. :-)

Re:How do they determine that?

[Anonymous Coward]

Ubuntu already does that.

Published unencumbered specs, not software.

[jbn-o]

No, we don't need organizations to provide their own software because then they'll distribute proprietary software. We don't benefit from dependency. I don't need to give up my software freedom to make some device work with the Linux kernel. I don't need software which will go unmaintained because nobody who is willing to do the maintenance knows how it really works.

What we need are accurate published specs for all hardware. These specs should be published for all to see, with no legal restrictions. And the hardware should not need firmware to work (or that firmware should also be free software). I'd rather work around hardware bugs in driver code than become dependent on a binary blob. This way we can write our own software that works with the hardware, maintain the software ourselves in perpetuity, and recommend everyone go buy that specific make and model (thus giving that manufacturer or reseller more business).

I'm happy to recommend certain devices on this basis. I'll choose that hardware even if it's not the most efficient way to get some job done because I don't have to fear it will stop working when I upgrade my system or switch to another free software OS.

It's important to not take a defeatist attitude on this. Having viable machines without giving up our software freedom (which is the main thing that separates free software OSes from their proprietary alternatives) is important.

monkey?

[Frank Grimes]

The announcement would likely get MORE response if it had been on an OSDL/Linux Foundation web page and signed by all of the major Linux players, rather than on a page titled "linux kernel monkey log". That said, I want Linux to succeed very much, and I think this is a good direction to take things.

Should always have been like that.

[ebingo]

Hardware specs should have always been freely available. What did companies have to worry about? As the FAQ tells, it only means more sales or at worst, as many sales as if the specs weren't available. It costs them nothing and they have nothing to lose, they'd just have to say: "We have a new product, here are the specs, have fun". I wonder why they never did that on their own.

Now, this is even better because of the NDA of the specs of not yet released products, which means support from day one!

OSDL/Linux Foundation - get on it

[Anonymous Coward]

I agree. I'd like to see the OSDL/Linux Foundation put out a more "official" promotion of this (the corresponding NDA is on their site). Of course they can't promise to produce drivers for every USB-powered plastic dogpoop nightlight. But they can say "hey we've got a legal/business-speak process here if want Linux kernel drivers for your hardware, and we know how to answer your manager's questions".

Don't knock it.

[Grendel Drago]

Consider that you don't need a special driver for a particular brand of ATAPI CD-ROM drive, or for a particular USB Mass Storage Device. Heck, Windows has USB class drivers for Bluetooth devices, smart-card devices, hubs, HIDs (keyboards, mice, CueCats and such), mass storage devices, printers, PTP-protocol scanners and cameras, audio devices, modems and video devices. Linux has a variety of supported class drivers as well. There are, of course, more classes, and that's all just for USB devices.

Sure, there are a lot of corner cases and pathological hardware--I think video cards are the best example--but it's entirely possible and indeed desirable to support all kinds of devices in the kernel. Even if sometimes we have to say goodbye to one of them, it was worth it to have them around.

Ah, it's in misc now.

[Grendel Drago]

Just a note: the trance vibrator driver is indeed in the mainline kernel; it's not in the "input" directory, but rather "misc", now, in case you were looking for it. Here it is. Amazing what they do with computers nowadays.

Re:Ah, it's in misc now.

[mrchaotica]

o_O Do I even want to know what that thing's used for?

Q: Are developers really going to do this?

[Chealer]

Greg, thanks once again for your wonderful blog, but I'm afraid that the absence of
Q: Are developers really going to do this?
indicates that you missed http://linux.slashdot.org/comments.pl?sid=219556&c id=17839388

Oh, it is. It is.

[Grendel Drago]

Oh, it's exactly what you think it is. I wonder if anyone's written a driver to have it thump along with the bass beat of whatever music you're playing.