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?

Comments

Excellent suggestion!

[scsirob]

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.

Re:Excellent suggestion!

[kmmatthews]

No, because we'd (at best!) get the same crap drivers that windows gets. Childish crap spewed out by the lowest bidder, and it destablizes the entire system. Not to mention that no open source coder can _fix_ the damn thing then.

Look at nvidias drivers on linux! Always well behind other drivers, and filled with bugs because we have to wait for nvidia to get off thier asses and fix the damn thing.

What happens in 10 years when you're trying to use that binary driver to recover data from an ancient device? If it was an open source driver, you could fix it to work with your system; binary, you're going to have a lot more work to do.

Re:Excellent suggestion!

[Dwonis]

It's not that I want to repeat anything, but there are a whole mess of hardware vendors out there that just won't release open source versions of their drivers.

No, no, no, no NO. We don't want hardware vendors to write drivers. Besides, most hardware vendors don't want to maintain drivers for Windows, MacOS, FreeBSD, NetBSD, OpenBSD, BeOS, HURD, Xen, Linux, Solaris, and each of the incompatible versions of each of them, as well as any new platforms that arise. Even if they do, whether or not they can write good quality, full-featured, secure drivers for all of these platforms is an open question.

All a vendor needs to do is to make good, solid interface documentation, and make it available without NDAs and other childish restrictions, and the drivers will not only be written, but they'll probably be shipped with the operating systems, and for the most part, just work.

Companies that specialize in PC hardware should stick to the hardware, and let the software specialists write the software.

Stability like that leads to stagnation and death

[A nonymous Coward]

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.

As the article says, it's illegal, and a bad idea

[SWroclawski]

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.

Userspace, anyone?

[ettlz]

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!

It's much worse than that...

[HotNeedleOfInquiry]

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.

Re:No Thanks!

[IamTheRealMike]

Three points.

• For many companies, there are no benefits to going open source, and only downsides. The pragmatist recognises this economic reality, the zealot (and Greg KG is a notorious one) doesn't want to hear it. For instance, let's say nVidia GPLd their driver and got it accepted into the main tree. This gives them a competitive disadvantage because ATI or other companies can now look at how their drivers work with much less effort. It doesn't save them any work, because the community would still expect them to maintain the drivers and add functionality to them (and indeed, for cards that are new to the market or in development, they'd be the only ones who could). And there's no guarantee the drivers would be accepted anyway - simply using the wrong coding style is enough to cause problems in the kernel project, let alone doing the sort of things the nVidia drivers do (for instance they used to use a custom TLS scheme).

  Because of this, I'm 100% not convinced making binary driver developers lives harder changes anything. Are large businesses (the type who make hardware that's difficult to reverse engineer) likely to say, hey, gosh, you know this Greg KH guy kind of doesn't like closed drivers, maybe we should open them up to please him? Nope. They'll just work around the difficulties or not provide drivers at all.

• It's not "impossible" to debug binary software. Please. This is a crappy excuse kernel developers regularly pull out of their asses to confuse people who haven't done much software development. What they actually mean is, "I don't really want to" (and if unloading the driver makes the crash disappear, that's a pretty good way to shift the problem onto the driver manufacturers anyway).

  I've been a Wine developer for years and have spent many hours doing this impossible thing of which you speak, and your average copy of MS Word or Steam is a LOT larger than your average driver. Yes, it's hard. No, it's not impossible. I've heard various excuses as to why kernel development is just different!! to userland software development, and don't buy it. Yes, having to reboot when a crash occurs is a royal pain in the ass, but so is not being able to get a backtrace because the game you're investigating treats any attempt at attaching a debugger as an attempt to hax0r its copy protection. Different space, different challenges. It's still possible.

• A stable binary module interface would help open source developers too (even if it only existed for a single 2.X series at a time), as new software which relies upon kernel modules or drivers would become much easier to distribute and install for non-technical end users. Take for instance ZeroInstall. The main developer, Thomas Leonard, since abandoned the original (imho quite elegant) approach of using a networked VFS because it required users to install a kernel driver, a task which proved hard to impossible for many non-developers. So the whole thing was rewritten to do things a different way and avoid the kernel, despite that coming with some disadvantages. We've also looked at using a kernel module to fix various speed issues for Wine in the past, but the difficulty of getting even minor patches accepted into the kernel let alone major new subsystems nixed that. If there had been a stable module interface we could have skipped all that and gone straight to improving things for end users without having to worry about what kind of indenting or list structure we should be using.

Re:As the article says, it's illegal, and a bad id

[SWroclawski]

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?

Re:This is the problem

[aeoo]

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.