Slashdot Mirror
Should Linux Have a Binary Kernel Driver Layer?
zerojoker writes "The discussion is not new but was heated up by a blog entry from Greg Kroah-Hartman: Three OSDL Japan members, namely Fujitsu, NEC and Hitachi are pushing for a stable Kernel driver layer/API, so that driver developers wouldn't need to put their drivers into the main kernel tree. GKH has several points against such an idea." What do you think?
Linux, with the stability of Windows prior to the advent of certified drivers.
Lets put it in Kernal 2.7.
Oh wait... OOPS!
Having a kernel API for drivers allows developers to stay away from the mainstream kernel. This will enhance the stability of the kernel in general and also allow hardware vendors to support Linux with less effort.
To Terminate, or not to Terminate, that's the question - SCSIROB
No thanks, this is just a great way to promote closed source inside the linux kernel and to make debugging problems totally impossible.
Shadus
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.
They'll think I've lost control again and leave it all to evolution. -- Supreme Being, Time Bandits
I gave up Linux mostly because I was tired of getting punished for having new hardware, which is often unsupported. Especially on laptops.
If you don't force the manufacturers to include their driver source in the kernel, you might get them to release actual drivers for their new hardware.
Toronto-area transit rider? Rate your ride.
One of Linux's great strengths is the flexibility of changing to meet new needs and not being hobbled by rigid backwards compatibility. This can only be done if all source is open and anyone can update drivers to meet new needs. When someone comes up with a patch to streamline a certain minor part of the kernel, it frequently has repercussions elsewhere in kernel land. It is these small changes which have made linux better and better with breathtaking speed. A "stable" binary API removes the possibility of keeping everything up to date and would dramatically show down the adoption of new features and general improvements.
Continual refactoring is worth far more than some supposed binary API which prevents changes. Get rid of binary drivers! If companies are so paranoid that they want binary drivers, then the hell with them. Linux can advance better without that baggage.
Infuriate left and right
These companies want a binary layer so they can build binary drivers.
What people tend to forget about this is that it's a bad idea- from most every perspective.
The Linux kernel was written as a Free Softwate alternative to the existing *nix systems.
We have thousands of drivers in the kernel from a combination of development efforts. Sometimes a driver is written by an independant kernel developer, and sometimes it's written from the company producing the hardware, working alongside the community.
What these companies want is to be able to have thier cake without giving back to the community. This is a very slippery slope at the least, and illegal at best, since these sorts of links to binary kernel drivers have been long known to be illegal to distribute alongside the kernel (unless special previsions are made, such as a userland driver).
Also, binary drivers have been known to be buggy and essentially removie the kernel developers from a position where they have control over the kernel as a whole project. I won't even go into the issues associated with a possible security hole in a binary driver, or a binary driver with, for example, spyware in it.
The arguement for it is, of course, that this might mean more drivers. This is a test of our strength as a community. Doing the right thing is harder. It means we won't have all the hardware at all times, and certainly not the newest thing. But we retain control over our computers.
It's hard to say no, but this looks like a clear case where we have to.
This is very welcome but unfortunately, I think they'll fail. There is just too much politics surrounding Linux these days.
It is not welcome. Linux is about Open Source, and allowing people to link-in binary closed drivers goes against this.
Too much politics surrounding Linux? Where have you been? It has been the policy of the Linux kernel for a long time that it would never stablize a binary driver interface, in order to prevent people from not making their drivers open source.
The idea behind Linux is that an Operating System should be Open, and Free (as in speech), and that nothing should hinder this. Binary drivers are exactly this sort of hinderance.
You may be upset that you don't have drivers for product XY because that company doesn't want to play along, but if you're trying to change the way the world does software, you can't go "ok, just because we *really* want your drivers, we're going to bend the rules for you."
I am unamerican, and proud of it!
IANAKH, but couldn't more drivers be moved into userspace (or other lower rings) --- especially for things like USB printers and miscellaneous gizmos? I think it would also be nice to not bundle thousands of drivers and support for architectures I don't have with the kernel. The kernel itself could provide a very minimal layer of hardware protection (like an exokernel?) and there'd be libraries exporting generic abstractions for particular classes of hardware. Is the context-switching penalty really so great these days? Educate me!
If a company is developing an embedded Linux ap for their own hardware. All of a sudden, all of the communications with the board-specific hardware is being done through binary drivers, resulting in an effectively closed system.
No more hacking WRT54G's for you, chump.
"Eve of Destruction", it's not just for old hippies anymore...
The BIOS is indeed an issue, and there are efforts underway to make a Free BIOS.
But why not try our best to have as much control as we can?
Wrong. It is closed source companies who put the code before the user. They protect the code more than they protect the users. Open source is about protecting the user by allowing unhindered access to code for modification and redistribution.
It's funny how you warp things around.
Linux is actually much better at this than windows - you can see what the kernel does. Microsoft's test suite means nothing, as explained by a (great) microsoft programmer: http://blogs.msdn.com/oldnewthing/archive/2004/03/ 05/84469.aspx
"In a comment to one of my earlier entries, someone mentioned a driver that bluescreened under normal conditions, but once you enabled the Driver Verifier (to try to catch the driver doing whatever bad thing it was doing), the problem went away. Another commenter bemoaned that WHQL certification didn't seem to improve the quality of the drivers.
Video drivers will do anything to outdo their competition. Everybody knows that they cheat benchmarks, for example. I remember one driver that ran the DirectX "3D Tunnel" demonstration program extremely fast, demonstrating how totally awesome their video card is. Except that if you renamed TUNNEL.EXE to FUNNEL.EXE, it ran slow again.
There was another one that checked if you were printing a specific string used by a popular benchmark program. If so, then it only drew the string a quarter of the time and merely returned without doing anything the other three quarters of the time. Bingo! Their benchmark numbers just quadrupled.
Anyway, similar shenanigans are not unheard of when submitting a driver to WHQL for certification. Some unscrupulous drivers will detect that they are being run by WHQL and disable various features so they pass certification. Of course, they also run dog slow in the WHQL lab, but that's okay, because WHQL is interested in whether the driver contains any bugs, not whether the driver has the fastest triangle fill rate in the industry.
The most common cheat I've seen is drivers which check for a secret "Enable Dubious Optimizations" switch in the registry or some other place external to the driver itself. They take the driver and put it in an installer which does not turn the switch on and submit it to WHQL. When WHQL runs the driver through all its tests, the driver is running in "safe but slow" mode and passes certification with flying colors.
The vendor then takes that driver (now with the WHQL stamp of approval) and puts it inside an installer that enables the secret "Enable Dubious Optimizations" switch. Now the driver sees the switch enabled and performs all sorts of dubious optimizations, none of which were tested by WHQL.
(IOW: it doesn't guarantee stability or quality at all. It's just a false sense of "stability")
First, I think you're missing the fact that, overall, Linux doesn't care that you can't put your binary-only drivers on it.
Linus has said publically many times that the reason that there is not ABI is because he doesn't want one. Binary drivers for *anything* end up screwing stuff up. When they do, there is NOTHING anyone but the original author can do. The code stagnates, users get shut out without any help and nobody is any the wiser as to how that hardware actually worked in the first place.
That's WHY there is stuff like the kernel module license tainting, so that the kernel developers look at a problem, see that you have the massive unknown of a in-kernel binary loaded and can instantly filter your report out. They don't care that your binary driver doesn't work. They can't help you.
Additionally, setting anything into a static position means that development of it ends and stagnates. You'll never get a static interface that you can use to extend the drivers when new features come along. You end up with all sorts of kludges and interface versioning to try to take account of new things.
Linux is developed as an independent operating system, not Windows 2006. No-one wants to make you use it if you don't want to. I doubt Linux was ever intended as anything other than a "pure", almost theoretical, system; that is, one that can be constantly redesigned from the ground up to the way it should have been, not kludged to make it fit your eight-year-old driver (which the author is no longer available to update) for a mouse that happens to still use the old interface.
"Frankly, linux desperatly needs both a kernel debugger, and an ABI to be a REAL alternative for many customers."
Whoa, magic word customers. Linux doesn't have customers. Your company may have customers. There's no obligation on Linux to help you get/keep your customers. People use Linux because they want to. How often does Linus appear on your telly begging you to buy into Linux? Never. Because he doesn't care if you do or not. However, I do imagine it feels pretty nice to him that you do want to use it.
"It also needs the ABI for driver developers so that we can write a single driver and expect it to work on the dozens of flavors of linux we are expected to support."
*You* are expected to support whatever you decide to make. Unfortunately, the linux kernel developers are expected to support YOU, your hardware and everyone else in the world. They don't because they cannot and have no reason to. Even if they had your complete source code, they cannot be expected to maintain your driver for you (which is what will happen when your company goes bust / gets bored with OS).
Sometimes the best-written drivers in the world are not taken into the kernel because they don't quite fit and the maintainance involved in keeping them in the kernel is too difficult. Your driver, if it is to have any support in the kernel, needs to be able to be updated on any kernel-coder's whim in order to make the whole a better system. You can't do that with binaries, you can't even do it with stable interfaces. You have to have the source.
The kernel coders have never promised that your stuff will always work (unless it is designed to run purely from userspace... several times Linus has says that userspace interfaces will not MUCH change over time.). They haven't because they cannot.
The nature of the system is changes to bring improvements, from the interrupt system to the IDE interfaces, from the schedulers to the userspace interfaces such as sysfs or procfs, Linux changes and evolves over time and they cannot guarantee that anything other than userspace syscalls and the like will not be broken, changed or improved between one kernel release and the next.
When the linux kernel people discover a new way to write drivers that sees enhancements across the board, chances are that they are going to break any of your "single driver" models. That's why they won't give you one. Them im