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.'"

Comments

Re:Performance

[corychristison]

If you'd have read the article, you'd notice that it states firmly:

However, DMA transfer between userspace and kernelspace is not yet implemented. This means essentially that drivers which involve high traffic are not an option yet. So graphic drivers as well as file system drivers and similar cannot use this API at the moment.

Like QNX, although not as clean

[Animats]

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.

Vista already has this (not trolling, read on)

[AlphaWolf_HK]

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.

Re:Vista already has this (not trolling, read on)

[Anonymous Coward]

You're half right.

Vista has partially user-space drivers for graphics, where the majority of the driver is in user space, and the kernel-mode component just allows communication between the driver and the hardware. Linux already has a similar architecture, as does MacOS X.

Second, it has user-space USB drivers. Which Linux and MacOS X have both had for ages.

It also has user-space printer drivers, which is no big deal - printer drivers hae been user-space only for years on most operating systems.

No other driver is user-space. They're all still in the kernel. They have modified the API and ABI for a lot of them, particularly sound (by removing all hardware acceleration) and network (because it interacts with the newer network stack).

Re:Vista already has this (not trolling, read on)

[wwahammy]

Actually it was there before Vista. Windows Media Player 11 came with the first version of the userspace driver framework. I think its used for media players that sync with WMP.

My understanding was that Microsoft recommended companies move to userspace not that it was required. To be fair though, I know very little about WDDM so they might have different requirements.

When I read the headline, the first thing I couldn't help but think was if the roles were reversed there would be hundreds of people saying "Good to hear you got something Linux had for a year already." Good ideas are good ideas. Why can't people just be happy when their ideas are recognized as good by others?

Useless API, for simple drivers only

[kscguru]

Maybe I'm unique in that I not only RTFA, but browsed the patches themselves.

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.

Re:Useless API, for simple drivers only

[suv4x4]

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.

Nice rant there. Let me summarize it:

"What is impossible in user space driver is kernel space features".

No shit. That's the point of a user-space driver. If you give a user-space app access to ring-0, it's no longer user-space. Or did you imagine there's some sort of unwet water that the stupid developers of the kernel keep missing.

The user-space driver is not set to replace all kernel mode drivers. Just like Vista, it's set to replace *some* of them, for example USB devices with low traffic. It's not a solution from heaven, it's just a reduction of fail-prone pieces that lurk in your system.

If you RTFA you probably had to read the summary as well where it's said user-space drivers aren't suitable for high-performance gear such as graphics cards.

Re:Better drivers and more of them

[ZorbaTHut]

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.