Slashdot Mirror
Linux Kernel To Have Stable Userspace Drive
liquidat writes "Linus Torvalds has included patches into the mainline tree which implement a stable userspace driver API into the Linux kernel. The stable driver API was already announced a year ago by Greg Kroah-Hartman. The last patch to Linus' tree included the new API elements. The idea is to make life easier for driver developers: 'This interface allows the ability to write the majority of a driver in userspace with only a very small shell of a driver in the kernel itself. It uses a char device and sysfs to interact with a userspace process to process interrupts and control memory accesses.'"
QNX has had user space drivers along somewhat similar lines for many years. In QNX, all the drivers are in user space, which makes for a much smaller kernel. Here's a simplified article on QNX driver writing.
The Linux approach has the problem that Linux doesn't have the message passing primitives that QNX does. So there's a special purpose mechanism to hook up these new user-space drivers to the I/O system calls. In QNX, "open", "close", "read", and "write" are actually C library functions that call MsgSend to do the work. (System V IPC isn't really suitable; it's asynchronous, which means a few extra scheduler events for every message pass when you try to use it for something that works like a subroutine call. Long story.)
Unfortunately, on x86 hardware, you can't protect the system from a user level driver and still give the driver direct hardware access. IBM VM mainframes get this right, but x86 does not. On the other hand, you can have channel drivers for the various types of x86 channels (SCSI, FireWire, USB, etc.) and make other drivers work through them.
User-level drivers cost you at least one extra memory copy of the data. That's not too bad in practice. I did a FireWire video camera driver for QNX, and when transmitting 640x480 24 bit images at 15fps, it took about 3% of a Pentium 4 CPU.
FWIW, not trying to troll, but thought I would point out that this feature is one of Vista's improvements over XP, and simultaneously the primary reason why Vista's compatibility isn't that great right now, and thus the primary reason why many people don't switch to Vista yet. Most of the hardware vendors have to make big changes to their drivers in order to accommodate this, especially nvidia who has to make about 4 different user space drivers (one for d3d, one for opengl, and an SLI version of both of those.) This is a good thing to have for both security and stability reasons, and I was waiting for when somebody would add this to the Linux kernel.
Linux has the advantage in that with Linux you can use both the old "kernel only" drivers, and the user space drivers at the same time. Vista could have done this as well, however Microsoft felt that if they allowed this to happen, then most hardware vendors would be lazy and continue to use their old kernel mode drivers, thus defeating the purpose. And to be honest, I agree with them. Linux doesn't need this on the other hand, as eventually somebody who is interested will make these kinds of changes to all of the open source drivers anyways as needed, which can't really happen because most windows drivers are binary only, so Linux can more or less take the "phased change" approach.
Disclaimer: I use both Vista and Linux (gentoo is my preferred distribution,) and am not afraid to say that I don't hate either of them, and rather like both of them.
Careful with names containing L slashdot.org/~AiphaWolf_HK slashdot.org/~AlphaWoif_HK slashdot.org/~AiphaWoif_HK
From TFA there is no DMA access to kernelspace. So other than keyboards and mice I don't see how this can be practical for anything, other than embedded applications as the article alludes to.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
Which led me to the conclusion that this patch set is worthless. It allows remapping of memory-mapped I/Os to a userspace app, and allows a thread to "wait" on an interrupt. Both are nice ideas, and it would be very easy to implement a nice serial port driver with the new APIs. (As any kernel hacker knows, serial port is one of the simplest device drivers; it's easy.)
The new API is completely useless for binary-only drivers. I/Os / IRQs are enough for extremely simple devices - these are, after all, the primitives for talking to hardware. But if this were all a driver needed, don't you think Nvidia / ATI would have used this model for shim drivers a long time ago? Simple things like DMA and PCI configuration access are not present - but to be fair, those are implementable with these primitives. Reality check: real world drivers are a lot more complicated. What is impossible is fast thread switching, kernel synchronization primitives, access to the network stack (wireless!), ring-0 CPU instructions, real-time timing access, and the huge reduction in context switches / cache flushes that comes from running within the kernel (moving code to user-mode increases latency by a factor of 3, roughly). Kiss the lag-free desktop goodbye as hard drive latency skyrockets, watch your 3D framerate drop by 70%, see your webcam stutter into unusability.
The kinds of drivers this API can support are the simplistic ones, the kind that are already GPLed and are already in the kernel, the 80% of devices in this world Linux has always had good support for. The kinds of drivers this API cannot support are 3D graphics, high-performance disk or networking, wireless networking, latency-sensitive USB or Firewire, the virtual devices (VMware, KVM, Xen, even /dev/tty) - notice that most of the devices Linux supports poorly (and all the common binary-only drivers) fall into this list.
To be fair, the official (e.g. from Linus) announcements I've seen only claim this interface is useful for embedded devices (which tend to code for a specific kernel, and not get updated). No official announcement claims the new API will help binary-only drivers. It's just the OSS-zealot crowd making unwarranted assumptions. Yes, this is the bad news: the stable userspace driver API will do nothing to solve binary-only driver dilemmas. Sorry.
A witty [sig] proves nothing. --Voltaire
on linux, getting updated drivers means clicking "update" when the GUI informs you that an update is available.
No, they are not.
It's happened before -- Broadcom for example. For the longest time, you could only run broadcom wireless with ndiswrapper. Now there's an open driver. You need only copy the firmware out of the Windows/OSX driver, and I imagine there might even be some free firmware developed eventually. This doesn't mean ndiswrapper is dead -- I'm sure there are other cards that still need it -- but Broadcom wireless cards now likely work better with the bcm43xx driver than with ndiswrapper.
Sometimes, it even happens with the manufacturer's blessing. For the longest time, the only way to get stuff on your nForce board to run was to load nVidia's proprietary nForce drivers. Now, nVidia never released source -- and perhaps couldn't, because of license restrictions -- but they now strongly recommend using the open "forcedeth" driver, which has surpassed their own in functionality and stability, and is actively supported by the kernel developers.
And sometimes, the manufacturer actually does it themselves. Though IBM kind of did a bad job of coordinating with the community, they did port Linux to their bigiron mainframes, and they did finally release all source back to the community.
Some manufacturers even seem to do this from the start -- syskonnect, for example, has full source code for a Linux driver available for download on their website, although I believe the kernel-maintained sky2 driver has surpassed their "sk98lin" driver.
So I don't think it's unreasonable that, very soon, you'll be able to build a Linux system without any proprietary code in ring 0. You might still want the win32codecs, say, but that's a different matter -- I don't really care if my movie player crashes once in awhile if it doesn't bring down my whole system -- and many of these are being replaced by free/open drivers.
In fact, you can do that now, if you're careful with your hardware choices. The only real hurdle to a desktop/laptop system with a completely open kernel is gaming -- you really want nVidia or ATI. It's been said that AMD/ATI are looking at opening up their drivers, and nVidia has actually produced a list of exactly what licensing issues they have -- I think they even named names of which companies have to sign to allow them to release all of their source. And anyway, if it doesn't happen, the community isn't waiting -- there is already at least one project attempting to create an open nVidia driver, and there have always been open drivers for older ATI cards.
Porting isn't the problem. Really.
All it would take, in many cases, is a hardware manufacturer releasing source for their Windows driver, and there'd probably be a Linux port out before the end of the week. We don't even need source code for all of them, of course -- just look at ndiswrapper and captive-ntfs -- but I think that just goes to show how easy it would be if we did have source, and they would perform better that way anyway.
I also remember seeing some quote somewhere that nVidia shares roughly 95% of their code across all platforms. Consider what they support -- Linux, BSD, Windows, OS X, I think they might even have Solaris in there somewhere. It's not unreasonable to think that the bigger and more complicated your driver is, the less of it needs to be platform-dependant.
Any program that can't easily be ported isn't modular enough to begin with.
No, I suspect the real problem proprietary manufacturers have is fear of licensing issues -- which userspace might help with, if they want to keep it proprietary -- and support issues. It's one thing to simply port to a different platform; it's another issue entirely to have QA,
Don't thank God, thank a doctor!
This is why I am prefer people who bother to learn English grammar.
I'm not sure they have to. For example, FUSE, an API for developing a filesystem in userspace, is GPL'd in its entirety, except for the library, which is LGPL'd. There is a Mac port, and the Mac kernel part is BSD licensed -- but the rest of it is probably the same GPL'd code. There's also talk of a Windows port, though I don't see anything about its status.
That's fine. I prefer to GPL my stuff. That way, I can always turn it into a commercial application, but you can't.
Can you give me one good reason why I should give you code for free, that you can then turn around and sell, without paying me a dime?
Again: Can you give me one good reason why I should give my code to Apple and MS for free, with no guarantee of anything in return?
There are large parts of Webkit (Safari's rendering engine) that are GPL'd.
Now, you may be right -- if they did anticipate having to lock it down the way they do now. But do you really think it would be a serious problem for them if they were on an open kernel?
Here's a hint: Oracle doesn't. Oracle sells all of their products for Linux now. And because of the GPL, every time they have to go in and make a change to the kernel to better support their database, we get it back. If it weren't for GPL, we might not have, for example, ocfs2.
This is your argument for BSD -- that MS would use it and not maintain an open source version? How is this any better than MS writing their own damned code, just like everyone else?
And just a little FYI -- Apple hasn't been particularly good at maintaining an open version of Darwin, and I'm fairly sure the rest of the Mac OS cannot be run on any Darwin except one they've compiled and signed themselves. That's not "open", that's tivo-ized to hell.
Ok, I get that you like BSD -- you like to freeload. And I get that BSD is great for MS and Apple, and everyone else who wants to freeload, or who has a legal department larger than some countries telling them that GPL is dangerous. I still don't see a single reason that I'd want to prefer a BSD license for my code over the GPL.
The only time I'd even consider it is if I was releasing the same code in a proprietary product, but that's what we have dual-licensing for.
Don't thank God, thank a doctor!
There are two ways to make new filesystems for Windows. You can make an Installable FileSystem (IFS) driver that runs in kernelspace, and you can make a Shell Namespace Extension to the Explorer shell. There is no shell-independent way of making userspace filesystems in Windows that I know of.
Note that I'm not a Windows programmer, but a Unix one. I did look into this however, when I was thinking of making an SSHFS equivalent for Windows, so that my friends and family could access my SSH server. I never got anywhere though, and settled for SftpDrive.
Keep in mind how much of a modern graphics card's abilities are now located in software. More than once, a driver update has come out that has *massively* boosted graphics card speed. I suspect that modern graphics cards are really just ultra-high-speed multicore floating-point coprocessors, and most of the scene logic happens on the CPU. I wouldn't be surprised in the least if the interface between CPU and graphics card was a tightly guarded secret - main bus bandwidth, and bandwidth in general, is one of the major bottlenecks on graphics systems right now.
To make it even worse, I'm told that many wifi cards are only legal because they're not open-source. Sound bizarre? When they're sold, they're sold with certain restrictions on frequency and power. These restrictions are located entirely within the drivers. If they distributed open-source drivers, those restrictions would either have to be moved into hardware (expensive) or disabled (causes horrific problems with the FCC.)
We're well past the point where hardware interfaces can be described in half a dozen pages. We're well past the point where "hardware devices" even exist entirely in hardware. Most interesting hardware devices have complex interfaces that depend on functioning backend software.
Breaking Into the Industry - A development log about starting a game studio.
The problem with this is that, since modern CPUs all use untyped memory semantics, they are forced to use typed-variable semantics, rather than typed-value, making the whole system no fun at all to program (unless you're into B&D languages).
I am TheRaven on Soylent News
Yes. The moderator guidelines suggest that you read newest posts first.