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?
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
Not just Heresy, but Linus has said directly that he doesn't want a stable binary kernel driver API percisely so that people *can't* write binary drivers for Linux.
I am unamerican, and proud of it!
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!
Please read The Linux Kernel Driver Interface (all of your questions answered and then some) by the same author before commenting...
It's been a while since I've worked on Windows drivers, but I believe certification also means that the driver has passed Microsoft's very rigorous driver tests. This test suite is much more thorough than anything a Linux driver has been through.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Just to play the devil's advocate - yes. That is, if you want the average Joe Blow to start even thinking about Linux instead of Windows.
Your statement has been the subject of several discussions here lately. If you are asking if "I" want the average Joe Blow to start using Linux, the answer is "I don't care". I belive the Linux is an excellent operating system that is stable, robust and powerful. I think average Joe Blow should use it for those reasons. Do I care if he does use it? As long as he doesn't call me to clean up his spyware and viruses, or at least doesn't get pissed when I charge him to clean it up, I'm fine with Mr. Blow using any OS he wants.
Thing is, if the Linux development community starts making compromises that jeopordize the security and stablility of the OS just to intice ol' Joe to use Linux we haven't gained anything. All of the reasons to use Linux go away and we haven't progressed. Linux has gained market share due to it's quality, stability and performance. Linux will continue to improve and continue gain market share because of these reasons. Eventually a free market should change to embrace a better product. There is no reason to compromise just for short term acceptance gains.
Find coupons in Greeley
For USB and Firewire that's already done. Both busses define like device classes and protocols those use. The actual devices need either no special drivers or those can be implemented in user space. Printer drivers (CUPS) are completely user space. Scanner drivers for Sane are completely user space.
It's already happening for scanners and cameras (see libusb) and serial/parallel port drivers (you don't need to insert a kernel driver for your parallel port printer, do you?). You don't really need a microkernel to write driver in userspace, just export the neccesary infrastructure in a sane way.
The day you can get third party IP licensors (e.g. that nice crossbar architecture used in previous-gen nVidia chipset memory control blocks wasn't developed in house by nVidia and they have contractual obligations not to release interface specifications for it) to agree to have their interfaces open by the licensees is the day you'll have fully open register-level documentation for consumer 3D graphics chips.
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
This is an inflammatory issue, but a stable interface doesn't necessarily open the kernel up to proprietary drivers. It's a matter of licensing. Any third party could introduce a GPLed abstraction layer. There are big practical advantages to being able to take a GPLed driver's object file and plug it in to any old kernel. In that case there would be no really fundamental reliability or debuggability problems. The remaining problem would be the increasing mismatch between the abstraction presented to the driver and the abstraction supported by the kernel as it develops.
It would be good to separate the discussion into two, one for inflammatory license- and/or ideology-related culs-de-sac, and another technical, to address legitimate needs for stability in drivers that are not (yet) in the kernel tree.
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
Oh, where do I start... I could talk about every one of your points.. lets just pick a few.. Firstly, the lack of hardware support for things like grandma's web cam, and caching SATA controllers hurts Linux much more than it hurts adaptec or joe blow's web cam co. If linux is to be just used by hackers for hackers that's probably fine. That isn't the impression I get from "linux people" who are constantly whining about lack of hardware support.
Additionally, setting anything into a static position means that development of it ends and stagnates.
Really? Could have fooled me... Windows can still run DOS and Windows applications from 20 years ago, linux can still run application from 10 years ago. When an API is created, usually there are hooks for extending it in the future. I wouldn't say either one has stagnated, over the course of the last 10 years. If that were the case windows wouldn't run on my quad 64-bit athlon.
*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.
But its our brand which gets damaged, when plugged into a linux box, and it works at 1/4 speed, or looses data because the developer who implemented the driver forgot some important edge case.
They really don't care about you and your binary drivers
No, but the weekly calls by linux users asking for them says that Linus and friends are only a small part of the community.
Stick a Knoppix CD in a computer and see how much of the hardware is supported by default. 90% if not more? Include binary-only winmodem/USB ADSL/philips webcam etc. drivers and you get close to 99%.
Sure, linux supports a lot of hardware, but there is a lot it doesn't support, or supports in a seriously half ass way. I would venture a guess that about 40% of the drivers in the kernel don't actually work based on my experience running linux since the early '90s. When I say don't actually work, i'm saying the driver cannot recover from rare hardware error conditions (like FC cable pulls for example), doesn't fully work. Doesn't work in all situations, for example SCSI adapters that work fine with harddrives but don't work with tape drives because they cannot deal with the rare condition of a tape drive returning check conditions and data at the same time. Or, works fine at some fraction of its rated capability. This isn't counting the fact that the kernel developers often break functionality in the kernel drivers when they change stuff and it doesn't get discovered for 6 months, because the developer making the change didn't test the driver that was affected. Now, your average slashdot weeny doesn't see this because they have standard whitebox or dell machines, that are the same as the other 90% of slashdot weenies. In real life there is a vast amount of strange hardware out there, professional audio cards, hardware encryption engines, 4 port fiber channel cards, ficon, 10G ethernet cards, large disk arrays, big memory systems, 10's of different types of system management interfaces for monitoring things like, system ECC soft errors, redundant power supplies status, etc. The list goes on. In many cases the linux driver was written and tested a year ago, a bunch of people are using it in a production environment and it has been broken for 6 months in the mainstream kernels. I was responsible for fixing a number of race conditions in the VMM a couple of years ago, that only occurred with a SMP box that had more than a couple G of RAM (a rarity back then). This was suppose to work, but it didn't because the people with 6G of ram didn't test it with SMP applications and the people with >2 CPU's didn't test with more than a few hundred megs of RAM. Recently I tried bench marking a 3TB disk array in linux, only to discover that it didn't work in over half of the file systems I tried (XFS, Reiser, JFS, ext2, ext3) and in at least one case worked but was so slow it was unusabl
"What is the difference between a $600 quadro and an outdated $85 Geforce4? THe firmwire is flashed differently and the drivers will optimize for accuracy vs performance between the 2."
That's not protecting IP, its protecting the fact that they are scamming customers.
"Also designs are copyrighted and if you open the source a competitor could argue that companyA neglected its copyright by opening it to the public, so therefore its ok to steal the design. May not be entirely true since copyright is designed to share work, but an ignorant judge could look at it as carelessness for being open."
You have absolutely no clue what you are talking about. Copyright does not need to be protected to be valid, that's trademark.
"WIFI is required to be closed and proprietary by the FCC under Powell. The government can revoke its license to produce wifi cards otherwise."
Yeah, that would explain why several companies have fully open docs for their wifi chips, thus enabling completely open source drivers for them.
The rest of your post is irrelivant windows nonsense that has nothing to do with the topic.