Slashdot Mirror

That's why Linux hackers want all drivers in the kernel tree, so they can find anything which breaks due to an API change, and fix the problems.

• Bug fix backports: Kernel hackers apply a patch to the latest vanilla kernel, then say backports are the distro's problem. Two distros do, fifteen don't, users of those fifteen scream at the hardware companies for having buggy drivers. With an out-of-tree driver, you just need to update the driver. Windows and OSX are light-years ahead of Linux here.
• Community contributions: Kernel hackers only add GPLed code; very few even allow dual-license, and certain vocal hackers are zealously GPL-only (to the extent of rewriting code JUST to make it GPLed). Which means the hardware vendor can't take a fix from a linux driver and integrate it into a Windows driver without GPLing that too. The vendor has to either GPL all drivers (Windows included), or maintain two separate trees (GPL and non-GPL), or not open drivers at all. Guess which is easiest / cheapest?
• Driver API stability: a modern 3D graphics driver is a full OS in its own right, with internal threading models, schedulers, memory management, context switches, etc.; a modern driver needs more than just bugfixes. Every good developer knows the way to keep two large codebases manageable is a stable API between them; the only people who don't seem to get this are otherwise-intelligent Linux kernel hackers.
• Kernel API freedom: Kernel hackers like stable userspace APIs (for good reason). But hardware vendors don't need to provide stable APIs if they have a shim library that actually talks to the cards (e.g. atioglxx.dll, the ATI OpenGL implementation). It's a lot easier to let the API change rapidly and only commit to a stable API at the library interface (the OpenGL API).
• Easier work. The Linux kernel development process is optimized for making the kernel hacker's life easier at the expense of the driver developer's (hint: saying "we'll update your driver for you" clashes very badly when the HW vendor is simultaneously making changes). If kernel hackers want to see better device drivers, they need to stop treating drivers as second-class citizens. Microsoft is very good at courting driver developers; Linux is the definition of arrogance.

You'd know all this if you'd ever tried to write a driver for Windows.

I've written several drivers for Windows. Incidentally, Windows isn't completely back compatible for drivers - they don't guarantee an XP driver will work on Vista for example. E.g. Win2k introduced WDM and plug and play to NT kernels which forced most drivers to be completely rewritten. The API for display drivers is very dependent on OS. Vista and later have a kernel mode framework which doesn't work on earlier OSs. NDIS has changed enormously, mostly for performance reasons.

Having said that it's not too hard to make a driver which works on two to three revisions of the OS, and usually with one binary. Probably you could do a driver which does Win2k, XP and Vista for example spending a couple of weeks coding and testing when the betas come out or bugs get reported, and that's 90% of the OS market. I.e. a few man months of effort over five years gives you a driver which supports the vast majority of computer users. Most companies only care about the last two revisions of the OS anyway.

But this is completely different from Linux where the interfaces inside the kernel change between minor kernel revisions without changing performance at all, and the kernel maintainers go out of their way to make it impossible to use binary drivers. So you spend endless effort supporting a platform with 0% of the market.

The cost/benefit ratio is enormously worse for Linux and even if you do it a people will just call you a leech because you didn't release the source code. Given that there's no commercial reason to do it, why bother?

If Linux ran on one type of processor architecture, a stable binary API might be possible. That's the reason Windows has been able to provide one for so long; there were/are discontinuities at major bit-width shifts (right now some people are struggling to get 32-bit drivers working on their new 64-bit Windows), but since the underlying hardware is basically always x86 things chug on with a simple driver model.

The fact that this is completely untrue for Linux makes a binary API impossible. Please read The Linux Kernel Driver Interface for more information; the "Binary Kernel Interface" section explains exactly why what you think should happen can't.

This isn't a political argument, it's a technical one. The only way to get a "stable binary API" into Linux would be to put a virtual machine-like interface on top of the kernel that drivers could talk to while being completely insulated from platform issues. While possible, the performance would be bad, and building/supporting that mess would turn into a political problem with the kernel developers.

Why do people continually make the same argument for a binary interface?

It's been addressed again and again and again.

Here's the definitive response.

Give it up.

No, I'm saying that once the code is in the main kernel tree, nVidia can still do all the testing. They can check out a the latest development revision, and run all their tests on all the hardware they own. If they find any bugs:

a) *nVidia* can report bugs to the lkml.
b) *nVidia* can send patches to the lkml to fix bugs before the next release.

*nVidia are just as capable of testing code in the mainline kernel as any kernel developer.* As nVidia does testing/maintenance of their kernel/blob glue now, they can continue to do it directly on the driver if the driver is in the mainline kernel, and continue to feed patches back. Only this time they'll get a lot more help from the rest of the kernel hackers. Even /if/ the glue layer makes their blob legal, they're still currently trying to game the system, and giving every kernel developer who has ever released /their/ code the finger, which isn't going to be making any of the kernel hackers predisposed to helping them at the moment.

If licenses and contracts stop nVidia from creating proper (read: GPLd and in the mainline kernel) drivers for Linux, but nVidia want to support Linux, then perhaps they should rethink which licences and contracts they sign. No-one's forcing them to sign anything....

You think you want a stable kernel interface, but you really do not, and you don't even know it.

Actually, if you talk the kernel devs, they'll tell you it's a feature, not a bug. They'll tell you that the problem is with Nvidia and that they need to release the source code to their drivers. The kernel devs haven't gone to any lengths to stop people like Nvidia from violating the GPL (they wanted to, but Linus put a stop to it), but they have stated time and time again, that they're not going to go to any extra effort to play nice with closed source drivers.

Nvidia doesn't really have much of an exuse in this case. All they can do is mumble some nonsense about IP. The Linux devs even offer free driver development with NDAs and all that jazz.

Even Debian does this automagically. I have to explicitly blacklist my sound module to stop the darn thing from loading all the time :o)

At around KDE 3.3.x linux surpassed windows in all counts.... At KDE 3.5.x linux came abreast with MacOS, and with KDE 4.0, linux will leave the shredded hulk of Mac OS in each it's waste, with wobbly windows, the beryl cube and other slick&useless features. And useful features, but since they never seem to matter... :O) The only reason to have windows now is if you are an avid adventure gamer or CRPG gamer; other gamers would be better served by PS3/XBox/Wii.

All of this is in my humble opinion, of course. :)

Nope. According to Greg Kroah-Hartman (the kernel dev who made the "we'll sign NDAs to write your drivers" offer):

Q: How are you going to write a GPL driver by signing an NDA? Is it going to require a binary blob or some other way of obfuscating the code?

A: No, not at all. I have written many drivers after signing NDAs with companies. They are usually signed either to keep information about the device private until it is announced at a specific date, or to just keep the actual specification documents from being released to the public directly. All code created by this NDA program is to be released under the GPL for inclusion in the main kernel tree, nothing will be obfuscated at all.

So there's a way to get free drivers, and now a major OEM wants to support Linux. Sounds like just the incentive that the "IP"-sensitive companies need. After all, Dell sells a lot of hardware.

I'm going to submit my driver... why? What are the chances, really, that this driver will be accepted for inclusion in the tree to run a device that nobody but me will ever even see, much less use?

The answer you're looking for is "none - no chance whatsoever". And for good reason.

The reason they're accepted is because it's valuable for the Kernel Devs to know the full range of hooks & interfaces that Linux is likely ever to need.

No, they don't give a damn about our sooper confudentiul hardware - but the hopes that similar hooks might benefit some other driver for some useful hardware in the future is more than enough to justify inclusion.

If you want a reference for this philosophy, one of the major kernel devs Greg KH explained more in his presentation at a linux conference keynote.

We want more drivers, no matter how "obscure", because it allows us to see patterns in the code, and realize how we could do things better. If we see a few drivers doing the same thing, we usually take that common code and move it into a shared piece of code, making the individual drivers smaller, and usually fixing things up nicer. We also have merged entire drivers together because they do almost the same thing. An example of this is a USB data acquisition driver that we have in the kernel. There are loads of different USB data acquisition devices out in the world, and one German company send me a driver a while ago to support their devices. It turns out that I was working on a separate driver for a different company that did much the same thing. So, we worked together and merged the two together, and we now have a smaller kernel. That one driver turned out to work for a few other company's devices too, so they simply had to add their device id to the driver and never had to write any new code to get full Linux support. The original German company is happy as their devices are fully supported, which is what their customers wanted, and all of the other companies are very happy, as they really didn't have to do any extra work at all. Everyone wins.

You may benefit from: http://www.kroah.com/log/linux/ols_2006_keynote.ht ml
  And look at this quote: "This just is not true at all. We have a whole sub-architecture that only has 2 users in the world out there. We have drivers that I know have only one user, as there was only one piece of hardware ever made for it. It just isn't true, we will take drivers for anything into our tree, as we really want it."
  So it all comes down to security through obscurity (which in your case would actually seem to make sense) and greedy managers (shoot 'em, shoot 'em quick!)

This just is not true at all. We have a whole sub-architecture that only has 2 users in the world out there. We have drivers that I know have only one user, as there was only one piece of hardware ever made for it. It just isn't true, we will take drivers for anything into our tree, as we really want it. We want more drivers, no matter how "obscure", because it allows us to see patterns in the code, and realize how we could do things better. If we see a few drivers doing the same thing, we usually take that common code and move it into a shared piece of code, making the individual drivers smaller, and usually fixing things up nicer.

http://www.kroah.com/log/linux/ols_2006_keynote.ht ml

Linux supports more devices "out of the box" than any other operating system ever has. Yes, even FreeBSD.

The other key highlight of this talk was:

Closed source Linux kernel modules are illegal.
Closed source Linux kernel modules are unworkable.
Closed source Linux kernel modules are unethical.

So who the hell is this guy? He's Greg Kroah-Hartman. Who the hell is that? He's a kernel developer. His name appears 149 times in my kernel sources (Ubuntu patched, 2.6.15). And, perhaps more tellingly it appears at the top of the files:

    drivers/pci/pci-sysfs.c and
    drivers/pci/search.c

both of which contain many functions which are called from functions in this file:

    NVIDIA-Linux-x86-1.0-8776-pkg1/usr/src/nv/os-inter face.c

What's that? It's wrapper for the closed source NVIDIA kernel module. What license is that under? The NVIDIA Software License. It's basically a proprietary EULA with a redistribution (without modification) exception for distros. It sure aint the GPL, or "as free" as the GPL (which is techically what the GPL requires for derived works).

So Greg.. why don't you sue them? You've made your position clear, fight them. If you havn't got the money, contact the FSF, assign your copyright to them, get them to fight. Given the choice between opening their source code or not being able to distribute their software at all, NVIDIA will choose to open their source code. How can I be so sure? Cause people buy their chipsets to integrate into things like set top boxes and other devices that run Linux. They need that embedded market, that's why they released the drivers in the first place. The problem is that no-one is making them choose.

Some compromises have to be made in order to survive a proprietary world

"There's a very good reason why Microsoft spends a lot of time on hardware compatibility -- it's what people want."

I agree with the last part of the sentence. Of course we all want things to work.

And first I'll admit I'm a linux programmer, user, I have like 6 machines at home all running linux.

My last experience is, my wife had to reinstall her windows box because of unstoppable spyware and viruses. And while the reinstallation was very much painless, a few hardware hasn't got the proper driver installed. The soundcard doesn't work, the TV capture card doesn't work. Display driver isn't the right one. And the worst thing is under windows we have no idea how to tell what hardware it is. Device manager says "Unknown device", details view gives no useful clue. It's her machine, she bought it, I've never touched or looked at it. And she has no idea what cards it has.

I ended up plugging in my USB stick bootable live linux and boot on her computer. At least I could use lspci to see what cards she has. And the best thing is, under the live linux, the sound card, TV capture card, and the display card are all working, with the right drivers.

I've also heard people spending an hour just installing a printer driver under windows, but it pretty much just works under linux.

For those who thinks windows has better hardware support, the only reason is they GET USED TO dealing problems with windows. People who don't know what to do to solve a problem under linux because they don't know linux, pretty much like me or many other people who don't know windows. My wife has installed/reinstalled windows probably a 100 times more than I have. Linux is a new world for them.

Micro$oft has done their job dominating the market, putting windows and BSOD everywhere. Ask any home users who have used windows 99% of their time, and they can tell you "all computers need constant rebooting and reinstalling, that's how it works, they just can't run for too long". They have no idea it's "windows", not "computers".

The myth, and truth with linux: http://www.kroah.com/log/linux/ols_2006_keynote.ht ml

At least according to this cat.

Personally, I think the best thing the Linux and BSD world has going for it is that Sun still thinks that it's all about the kernel. Nobody is ever going to switch to Solaris for dtrace, zones and zfs. 64bit filesystem vs. 128bit? Wake us up when it actually matters, if it ever does. I'm not saying kernels don't matter but the differences between various ones the features and lacking feature set is becoming small enough to not really care. The benchmark differences are so small and the stability differences aren't measurable.

The worst thing is that Apple seems to have their head out of their ass on this and working at getting in to "server space." They aren't afraid to challenge anything either. I kind of like how launchd works, it's not init and that's the point. It's not SysV init scripts either. That's just a small part of the treatment though. By the time they get real with it, who knows what they'll have done?

BSD and Linux both have pretty high viscosity when you get down to it. Linux is the wild west, lot's of things change but it all stays pretty much the same. BSD are up in their ivory tower so disconnected from the rest of the world... (They still think FreeBSD is "more stable" which might have been true at times during the 4.2 and 5 releases but I think it's hard to make that claim against any of the 6 stuff.)

An "easy to port" kernel is nice, as often as you do that. Personally, I've done it exactly one time and it's wasn't nearly as hard to do with Linux as you might expect. It's not a selling point, you know? It appeals to a very very tiny sliver of the user base, heck, it's a tiny sliver of the development community.

As serving platforms the area where the BSDs and Linux will fall behind is userspace. There isn't a programming framework, most apps on these platforms start with C code and syscalls still. The tools are all fairly raw. I assume that Sun and Apple will be playing ball for real, they are banking a lot in this new "UNIX" world... The GNU tools and such made UNIX feel a lot better but we havne't done much since then.

Also read this document.

VMware wants the Linux kernel to support a closed-source interface with an API that is not subject to change.

As Greg KH pointed out in his keynote at the recent 2006 Open Linux Symposium (mid-July), closed-source kernel modules are illegal and the kernel developers will do everything they can to prevent them. Besides the fact that they're illegal (in the view of many of the top kernel developers who would be responsible for approving the patches), they also consider them unethical. So even if they were somehow persuaded to include such an API from the legal standpoint, they find it morally reprehensible and would likely refuse on those grounds.

The folks at Xen aren't much better. They think an open source implementation is good, but as you point out, they want it tailored just for them. Linux has always been about choice, so I doubt that viewpoint will prevail either.

Instead, there needs to be a middle ground between these two extremes, or the Linux kernel will never get a hypervisor.

You might want to read this: http://www.kroah.com/log/linux/ols_2006_keynote.ht ml

"The point is, would specifying a stable kernel ABI *stop* it from changing "FOR THE BETTER" ? Everyone else manages to do it, why can't Linux ?"

Because stable ABI for binary-drivers is not in the best interest of Linux? Linux-developers want the drivers to become part of the kernel, where they can be properly troubleshot. If they provide a stable ABI, companies will just use binary-drivers, and no-one (except the manufacturer) has any means of troubleshooting the problems the drver might be causing. The biggest reason for instabilities and crashes in Windows is the drivers. If linux had a stable ABI, we would have that problem in Linux as well.

Read what Greg Kroah-Hartman has to say about it: Link. this also touches on the subject.

"The point is, would specifying a stable kernel ABI *stop* it from changing "FOR THE BETTER" ? Everyone else manages to do it, why can't Linux ?"

Because stable ABI for binary-drivers is not in the best interest of Linux? Linux-developers want the drivers to become part of the kernel, where they can be properly troubleshot. If they provide a stable ABI, companies will just use binary-drivers, and no-one (except the manufacturer) has any means of troubleshooting the problems the drver might be causing. The biggest reason for instabilities and crashes in Windows is the drivers. If linux had a stable ABI, we would have that problem in Linux as well.

Read what Greg Kroah-Hartman has to say about it: Link. this also touches on the subject.

Kernel modules have an well-known API, just like user-space programs.

The API for kernel modules is covered by the exported symbol names that the modules link against. This is no different than calling routines that exist in a shared library with a known API. These APIs are relatively stable within the same major kernel release (2.4, 2.6, etc.).

Not unless you have a pretty inclusive definition of "relatively stable". Have you looked, e.g., at LWN's list of 2.6 in-kernel API changes?

Yes, you can technically read from and write to any memory area in the kernel's memory space, but this is extremely dangerous without using the supplied symbol names, especially as locations of most things will change from kernel build to kernel build.

The API includes "functions" that are just macros or otherwise inlined into the caller's code, and hence expect to know e.g. structure layouts that may change from one kernel version to the next or one .config to the next. (Try inserting a module into a kernel that was defined with different values of CONFIG_PREEMPT or CONFIG_SMP....)

It can be argued that fixed APIs will hurt the kernel itself as the amount of glue code to keep old things poking at the internals rises along with the need to never change things causes unintended side effects.

I was chatting to Linux kernel developer about a year ago and he described how in the early 90s he found a remote security hole in a closed source operating system. He let the vendor know but the vendor did not patch the hole for over a year. To fix the hole the vendor had to change the API (which of course was set in stone) which would break all sorts of other things so the problem sat around unfixed until the next major release of the operating system.

The number one reason for running an out of tree driver on Linux is because it is a binary driver. And there are Linux developers who don't want to help binary driver developers. The prerogative is with the Linux devs - it's their kernel and perhaps it is those very open drivers that are keep said developers working on it. Secretly, I think you need the resources of Microsoft to produce APIs that don't change for years on end and support a large range of software but I'm told the NetBSD folks do this too. Why don't people simply use NetBSD rather than complaining?

Or Linux.

That's why you're seeing constant local kernel exploits. They're adding features too fast to consider the ramifications.

Why should I care about NetBSD? Linux runs on more platforms, and doesn't make audio skip if you try to rip a CD at the same time...

Kids and everybody want to print their photos. Can Linux print photos?

It depends on the availability of drivers for Linux. Are there printer drivers for Linux? I checked hp.com, canon.com and epson.com. NO DRIVERS FOR LINUX.

Why NO drivers for Linux? Apple OS X is Unix, use the same CUPS and drivers available for Apple but not for Linux. Is it the market share? Linux has bigger market share than Apple. Then WHY?

Do you know why? It is ILLEGAL to develop drivers for Linux!!!!!!!!!!!!!

Read more:
1. http://linux.slashdot.org/article.pl?sid=05/11/08/ 1915218&tid=4&tid=8&tid=106
2. http://www.kroah.com/log/2005/11/03/

So kids want to use Linux?

Get 'yer panties back on.

A presentation was released at his followup post (the one the submitter omitted). The companies made the following points:

1. They wanted the API to be optional
2. They wanted the API to be GPL'ed
3. They wanted the API to be incompatible with binary drivers
4. They wanted a stable development platform

This covers every discussion on this topic (above this post).

http://www.kroah.com/log/2005/11/07/#osdl_gkai2

Some misunderstandings were made. But of course, if they posted this link, there'd be no point to posting TFA or the arguments that will almost certainly follow. :-)

It's a myth that NetBSD runs on more than Linux. See gregkh's writeup.

Not meaning to be a Linux fanboy, but according to this post by Greg KH, key Linux kernel developer, Linux runs on more archs than NetBSD. But you might be right about NetBSD being able to run on more _old_ archs, though.

Some people argue that linux may have more arches than netbsd

even if is't not more or the same number: Linux runs on any hardware I can deam with and its constantly being ported and in some cases developed by the same companies who develop the system.

It isn't a good idea and here's why.

Giving in to the hardware companies' (pointless) fear of losing so-called "intellectual property" by opening up their drivers would pass part of the control of the kernel from Linus & co. to countless programmers who may or may not have special interest in improving Linux specifically. The quality assurance that currently takes place for the free software drivers that get into the kernel is valuable.

Giving up on free/open source software at every turn where it is convenient would lead us to having an OS that is an assortment of non-free parts a bit like the current proprietary UNIXes. It might even lead to someone eventually getting into a position where they could charge for an essential part of the system thus rendering it non-free even in the beer sense.

For a kernel developer's take on this, read this, it's from Greg Kroah-Hartmann's blog:

But the issue of driver compatibility. For all of the people that seem to get upset about this, I really don't see anyone understand why Linux works this way. Here's why the Linux kernel does not have binary driver compatibility, and why it never will:

• We want to fix the bugs that we find. If we find a bug in a kernel interface, we fix it, fix up all drivers that use that api call, and everyone is happy.
• We learn over time how to write better interfaces. Take a look at the USB driver interface in Windows (as an example). They have rewritten the USB interface in Windows at least 3 times, and changed the driver interface a bit every time. But every time they still have to support that first interface, as there are drivers out there somewhere that use it. So they can never drop old driver apis, no matter how buggy or broken they are. So that code remains living inside that kernel forever. In Linux we have had at least 3 major changes in the USB driver interface (and it looks like we are due for another one...) Each time this happened, we fixed up all of the drivers in the kernel tree, and the api, and got rid of the old one. Now we don't have to support an old, broken api, and the kernel is smaller and cleaner. This saves time and memory for everyone in the long run.
• compiler versions and kernel options. If you select something as simple as CONFIG_SMP, that means that core kernel structures will be different sizes, and locks will either be enabled, or compiled away into nothing. So, if you wanted to ship a binary driver, you would have to build your driver for that option enabled, and disabled. Now combine that with the zillion different kernel options that are around that change the way structures are sized and built, and you have a huge number of binary drivers that you need to ship. Combine that with the different versions of gcc which align things differently (and turn on some kernel options themselves, based on different features available in the compiler) and there's no way you can successfully ship a binary kernel driver that will work for all users. It's just an impossible dream of people who do not understand the technology.
• Drivers outside the kernel tree and binary drivers take away from Linux, they give nothing back. This was one of the main statements from Andrew Morton's 2004 OLS keynote, and I agree. Out of the box, Linux supports more hardware devices than any other operating system. That is very important, and is something that we could not have done without the drivers being in our tree.
• If a kernel api is not being used by anyone in the tree, we delete it. We have no way of knowing if there is some user of this api in a driver living outside on some sf.net site somewhere. I have been yelled at for removing apis like this, when there was no physical way I could have possibly known that someone was using th

And a good rebuttal from a linux kernel hacker.

If your hardware wouldn't fry in the process, you could rip the video card out of a runnig machine, and replace it.
Actually, there are people working on this for the linux kernel at least See this page or the May issue of Linux Journal page 54.
I imagine that similar capabilities could be coded for any BSD as well.