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

Better drivers and more of them

[Billly Gates]

A stable kernel api for drivers is what linux needs as proprietary driver writers make poor quality and buggy implementations. While this is not a kernel one its a good compromise as proprietary drivers are here to stay as much as it would be great if we had free gnu ones inside the kernel.

I wonder if it would be easy to port it to windows and macosx? IT would be cool for hardware makers to have a driver that works with all operating systems with minimal effort in porting. Costs are one of the issues besides the difficulty in porting windows drivers to linux which many makers do not bother doing.

Re:Better drivers and more of them

[whomeyup]

There's a userspace drive framework on Windows, but the vast majority of Windows drivers reside entirely in kernelspace.

Re:Better drivers and more of them

[ozmanjusri]

Drivers are very OS-centric; they tell the OS how to interact with the hardware and, of course, Linux and Windows have very different ways of interacting with hardware.

That still doesn't preclude universal drivers. In fact, Linux can already use some Windows drivers via ndiswrapper.

I agree with the GP poster, it would be a wonderful thing for computer users, but suspect Microsoft would put VERY heavy pressure on any hardware maker who looked like participating in that sort of development.

Re:Better drivers and more of them

[chromatic]

Costs are one of the issues besides the difficulty in porting windows drivers to linux which many makers do not bother doing.

If only there were some magical pool of experienced labor just waiting to write and maintain, in perpetuity, Linux drivers for any manufacturer of any hardware....

Re:Better drivers and more of them

[howlingmadhowie]

no one wants the driver. what the developers what is documentation for the connectors to the motherboard. surely this should be a legal requirement for the manufacturer anyway. i would regard it as the minimal acceptable documentation for the product. it is, after all, my computer the hardware will be attached to.

i would personally like to see all pieces of hardware sold with schematics for the hardware. with other products, like cars, this is trivial anyway--anybody can open up the car and see what bit goes where. with computer hardware, because of things like microcode, this is impossible.

and as for intellectual property. what strikes me is how this phrase is always used to protect the financial interests of a company against the greater good for society and the individual. if someone would instead be honest and say "companies are allowed to require society to install software (which does what exactly?) and use a particular operating system if the user wants to use their hardware, so ensuring (at the least) that the product will soon be unusable" then i'd have less against the people who champion this position

in the best case, this is built-in obsolescence. one thing i find repugnant is the attitude that it is morally okay to force society into this position.

Re:Better drivers and more of them

[howlingmadhowie]

for a start, it's not "other people's", it belongs to a company.

secondly, there already exists a framework to protect intellectual property. we call it the law.

thirdly, i don't see how anything is being taken away from the company.

i suppose what i'm really against is technology being used to restrict the freedoms and capabilities of the individual when the safety of the individual is not at stake. by all means the law can be used, but the law always has to consider the freedom of the individual first.

Re:Better drivers and more of them

[Anonymous Coward]

i suppose what i'm really against is technology being used to restrict the freedoms and capabilities of the individual
In the case you're arguing for, how is the technology restricting the freedoms and capabilities of the individual?
You can still work out yourself how to communicate with the device, you can still work out the motherboard connections etc. What you really want is a free handout. The companies that make tech products are under no obligation, moral or otherwise, to help you there. The only moral obligation I see them as having is not preventing you from figuring it all out yourself.

Re:Better drivers and more of them

[adamofgreyskull]

They are hardware manufacturers. They sell hardware. What the fuck do they have to worry about if they provide documentation on the interface between their hardware and the hardware under my desk? Am I going to suddenly be able to infer the entire design of their hardware (or the source of the drivers they've written for windows), just because I have that knowledge?

Am I missing something here?

Re:Better drivers and more of them

[Roydd McWilson]

It is possible to run untrusted code in the same address space as trusted code.

Fo sho, or more aptly, you trust the code not cuz some smart fucker wrote it, but due to the fact you fuckin' PROVED it safe relative to yer favored semantics.

The downside is, it would be incredibly difficult to do this with precompiled x86 stuff at all, and probably impossible to do it without a performance hit compared to simply running in its own address space. I'm not even sure it could be done efficiently with C source -- it would most likely have to be a sufficiently high-level bytecode language, at least.

True 'nuff to some degree, however, a nigga could see translatin' C to a stylized "driver C"... and WOAH! sneak in some type safety 'n shit. Toss in linear types, effect analysis, critical section termination, resource bounds... damn!

Which means that, probably, no one will ever do it. In order for this to work, it'd have to both be sufficiently better than Linux to get a majority of Linux developers to move over, and it'd have to support all the old Linux drivers, at least, until they could be rewritten.

Dem's da breaks, ain't dey? Ah one day one day ma pretty. The ol' em-dollarsign's got Singularity, but you know, them ain't no Linux friendly buncha bastards.

Re:Better drivers and more of them

[SanityInAnarchy]

While this is not a kernel one its a good compromise as proprietary drivers are here to stay as much as it would be great if we had free gnu ones inside the kernel.

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.

IT would be cool for hardware makers to have a driver that works with all operating systems with minimal effort in porting.

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,

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.

Re:Better drivers and more of them

[Jah-Wren Ryel]

Am I missing something here? Yeah. Patents.

They are afraid that by providing documentation on interfaces, it may tip-off a patent holder to start looking for infringement where they might not otherwise have done so.

After all, when the prevailing legal advice is to actively not look for pre-existing patents, it is inevitable that companies will independently create infringing hardware. It's like we get the worst of both worlds - patents might as well be trade-secrets since reading them is a legal mine-field if you are working in the same area, but we also get government enforced monopolies that stifle competition.

At least the lawyers get paid for their contributions,
and that's all that should really matter in the end. Right?

Re:Better drivers and more of them

[TheRaven64]

He's not wrong, he just has a lot of faith in type theory. This is the principle behind JNode and Singularity. If you're still reading books on OS design from the '80s or '90s, you might want to pick up a newer one (or, better, a copy of a recent journal in the field).

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).

Re:Better drivers and more of them

[ray-auch]

Am I going to suddenly be able to infer the entire design of their hardware (or the source of the drivers they've written for windows), just because I have that knowledge?


No - but that isn't their argument.

Suppose you get an email from Ferrari saying their new API for their F1 car has control functions for a moveable floor.

Will that enable you to infer the entire design of their car ? - No.

No suppose Maclaren get that email. Will it affect the competition between them and Ferrari ? - quite possibly.

In both cases, I don't know enough to decide if the argument is completely valid - but both are credible.

Re:Better drivers and more of them

[Haeleth]

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.)

This makes no sense whatsoever. Why can't they just release the driver source code with a note adding that it is illegal to use the driver if you remove the restrictions?

You might as well say that it is illegal to make open-source FTP programs, because only closed-source FTP programs could include effective restrictions to stop them being used to download child pornography.

Re:Better drivers and more of them

[Ornedan]

Except we're talking about commodity hardware here, so the competitor can get their hands on the actual hardware. And assuming they are not totally incompetent, they should be able to find out how that hardware works through direct examination.

Re:Better drivers and more of them

[drinkypoo]

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 don't know precisely what the situation is here but my understanding is that at least older geforce cards specifically implemented pretty much all of Direct3D directly on-card. The driver basically handled configuration and errata - when they fuck up the hardware, they fix it in software. The driver will be more a map of their failings than a catalog of elite code.

Re:Better drivers and more of them

[Skapare]

Keep in mind how much of a modern graphics card's abilities are now located in software.

Yes. But does that mean software that runs on a CPU on the graphics card, or software that runs on the system CPU, stealing cycles from it? The latter is what some manufacturers are doing, and should not be doing. For software that runs on the graphics card CPU, it doesn't need to run either in kernel space or user space ... that's another space we can call "hardware space". It has no access to kernel APIs or user APIs, nor should it have that.

Imagine for a moment if X Windows were the universal graphical system on (nearly) call computers. It isn't due to the likes of Microsoft, but just imagine it were. What we could have is a graphics card with a CPU on the card that implements an X Windows server. Then all you need is a way to shuffle all the messages that go between applications and X across the bus between system CPU and graphics card.

Now X might not be the best interface design, and certainly would not be for gaming, a better design certainly can be made. But even X would be faster than it is now with the server on the card (quite doable today). And still, the window manager would run in user space.

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.

That interface should be nothing more than the information of what the system and applications expect the graphics card to display, an encapsulation protocol to organize it into messages and responses, and a basic way to stream it across the bus (like PCI-Express x16, for an example with high performance). Those messages may possibly be a reflection of the graphical API calls done by the applications.

... those restrictions would either have to be moved into hardware (expensive) or disabled (causes horrific problems with the FCC.)

What do you think is happening now with quite a number of wireless routers being booted (or boosted) with Linux or BSD on them?

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.

That is certainly something that is happening. But it most certainly is not something that is necessary. What we have these days in designs are the result of companies trying to cut their costs with the consumers be damned. These are bad designs, not so much because they steal CPU power from the consumer's computer, but more so because they create these massively complex interfaces that keep changing all the time, and driver code that is so buggy it is frequently the source of systemwide crashes or data corruption. At least if that buggy code is moved into a process, it can do its thing without taking down the whole system.

But we shouldn't have to be doing that. The hardware specific code should be inside the hardware, running on the CPU that comes as part of that hardware. Upgrades can be provided by the system CPU as a checksummed and, if necessary, cryptographically signed, blob (via a unified firmware image upload interface design that all devices should share that includes device match checks to be sure the correct image is loaded). Then maybe we'll start getting some real value add out of things like video cards, instead of getting cards that result in a net loss of CPU power when added in.

Re:Better drivers and more of them

[ZorbaTHut]

But does that mean software that runs on a CPU on the graphics card, or software that runs on the system CPU, stealing cycles from it? The latter is what some manufacturers are doing, and should not be doing.

Why not?

Seriously, why not? Do you honestly think they should be building an entire separate general-purpose CPU, and putting that on the graphics card? If they can achieve better FPS - overall FPS, including what's "stolen" from the CPU - by putting heftier more special-purpose hardware on the video card, and falling back to the CPU for the stuff the video card can't do well, why shouldn't they?

I fork over money for graphics cards because they make my games look better and play better. Fundamentally, I don't much care how they do that.

Yes, obviously, moving more stuff to the graphics card would be faster. It would also be more expensive. If there are better ways for them to use the transistors, it's fine by me.

That interface should be nothing more than the information of what the system and applications expect the graphics card to display, an encapsulation protocol to organize it into messages and responses, and a basic way to stream it across the bus (like PCI-Express x16, for an example with high performance). Those messages may possibly be a reflection of the graphical API calls done by the applications.

What we have these days in designs are the result of companies trying to cut their costs with the consumers be damned. These are bad designs, not so much because they steal CPU power from the consumer's computer, but more so because they create these massively complex interfaces that keep changing all the time, and driver code that is so buggy it is frequently the source of systemwide crashes or data corruption. At least if that buggy code is moved into a process, it can do its thing without taking down the whole system.

But we shouldn't have to be doing that. The hardware specific code should be inside the hardware, running on the CPU that comes as part of that hardware. Upgrades can be provided by the system CPU as a checksummed and, if necessary, cryptographically signed, blob (via a unified firmware image upload interface design that all devices should share that includes device match checks to be sure the correct image is loaded). Then maybe we'll start getting some real value add out of things like video cards, instead of getting cards that result in a net loss of CPU power when added in.

Why? You're making claims, but you're not backing them up.

Here's what I see. I see that I can go to the store and pick up a new graphics card. I can plug it into my computer and suddenly my games run significantly faster. Now, if I have a choice between Card A and Card B, and they're identical in every effective respect except that Card B makes my games run 10% faster with better shadows and uses some nasty techniques to do so that I completely don't have to care about, I'm buying Card B. There might be philosophical arguments to be made about whether Card A or Card B is better, but in all honesty, I see these philosophical arguments as similar to the whole Hurd vs. Linux debate. Okay, Hurd might be "better" - but Linux works.

What they're doing with the cards right now works. They've poured millions of man-hours into making them as fast as humanly possible within budget. If they determine that it's best to use CPU power for some things, make the GPU into a half-FPGA, and use a complex binary protocol that changes based on how the GPU is programmed, and they can make all of that stable - and my computer literally hasn't bluescreened in a year, so I'll give them that much - I think, just maybe, you should respect that they're making the right decisions for the priorities that people have. Which, generally, is game performance per dollar.

If you want to keep metaphorically extolling the virtues of Hurd because it's "better", though, I'm certainly not going to stop you.

Re:Better drivers and more of them

[ScrewMaster]

Interesting. Now I have a wireless router running alternate firmware, and one of the options is to adjust output power from 1 to 251 mw, which would be way above the legal limit, I understand. As it happens, I used that option to reduce the power from the stock value, since the computers upstairs work fine with the router set to 24 mw. In my case, having that capability reduced my chances of causing unwanted interference. Not everyone wants to blow away their neighbors. Also, since the router is located in the basement and is running at minimum power, it's very hard to pick up a signal outside my house, and that's the way I want it. Encryption is all well and good but if they don't know it's there, so much the better.

Re:Better drivers and more of them

[level_headed_midwest]

They could, and with the signed drivers being required for at least 64-bit Vista, they could enforce it. But I'd be VERY willing to bet that if Microsoft even hinted at this, the hardware maker would just have to threaten to call the DOJ and Microsoft would backpedal faster than you could say "antitrust."

And you also mentioned the other solution if Microsoft does make threatening noises. With both the Windows and Linux kernel driver APIs being stable, it should be trivial to make a translation wrapper between the two. MS would have their hands tied in keeping drivers off Linux if that happens as they'd have to stop their own driver development. MS needs as many good drivers as they can get for even 32-bit Vista, let alone anything 64-bit. If I were Microsoft, I'd be helping out all I could to get a stable wrapper or translation layer so that a "universal" driver for both Linux and Vista could be made by device manufacturers. Vista notoriously lacks drivers, especially Vista 64-bit, and Linux has enough to make most things work, especially for corporate machines and in server rooms. Both of those areas are ones that are much more likely to consider switching to Linux from W2K/XP than to Vista than the ordinary Joe. Or they will sit on XP like many sat on W2K until around the time XP SP2 came out. Both results would give MS no sales, and since they are also MS's most profitable markets, not upgrading to Vista would be a serious blow to MS. So I think that taking a risk that some previous 2K/XP switch to Linux because of more driver support is far outweighed by the increased number of Vista sales because of better driver support.

Re:Better drivers and more of them

[FireFury03]

Do you honestly expect nVidia to cripple 99.9% of their market in order to placate 0.1% of it? That's what changing the interface to be "simpler" would do.

Who said anything about crippling or simplifying anything - just publish specs for the existing interface. This doesn't require opening up the secrets of how the driver works, just the interface between the driver and hardware.

Do you honestly expect nVidia to give up trade secrets in order to placate 0.1% of their market?

In keeping something secret if it doesn't benefit you - I don't see how publishing interface specs harms them. If anything it might improve the value of their hardware by allowing more people to use it for non-standard stuff.

nVidia doesn't have even close to the financial incentive to open their drivers

Noone wants them to open their crappy unstable drivers - we just want the interface specs so we can write some Free drivers from scratch.

As you've mentioned, Intel drivers are open - use Intel GPUs and it'll work just fine.

Intel don't make discrete devices - they make integrated chipsets. If you don't have an Intel processor then you're SOL. I have no interest in replacing my entire machine in order to get 3D graphics, but I would replace my graphics card.

Full circle?

[MichaelSmith]

Perhaps in ten years time Linux will be a microkernel

Re:Full circle?

[Tumbleweed]

Microkernels are the wave of the future.

And always will be. :)

Re:Full circle?

[init100]

Window's has a userspace driver framework as well as a FUSE equivalent (I think)

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.

I thought I read Uberspace

[TheRistoman]

So I immediately thought of a spaceship running Linux... I mean, could it really be otherwise?

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.

Finally...

[Statecraftsman]

The lack of a stable userspace driver api was that last thing stopping soccer moms and grandmothers from running Linux on the desktop.

My sarcasm is so extreme, I think what I said above may have actually been true.

Re:Finally...

[zullnero]

Considering that the major blocker for the average person in regards to making the switch to Linux happens to be driver support, then yes, it could make it easier for "soccer moms and grandmothers". Of course, that should be pretty obvious from even the article summary.

Re:Finally...

[howlingmadhowie]

on linux, getting updated drivers means clicking "update" when the GUI informs you that an update is available.

Re:Performance

[jd]

There's a 21us hit every time you context-switch, which would hurt on very high-performance drives but is probably below the threshold of being obvious for network-based storage and really slow drives. However, a few intelligent drives supposedly support total kernel bypass and zero-copy - basically the drive remote DMAs the data into and out of memory, once told where things are. This would only require kernel access for initializing the transfer and locking down the pages. I seriously doubt, though, that any of these will be common uses for the userspace drivers.

The most common use, I would imagine, would be as a testbed platform. Writing things directly into the kernel has many unquantifiable variables - I'm highly respectful of all who develop kernel code on a regular basis, that is no small achievement. Developing the same code in userspace with an API to link over eliminates many of the possible ways you can screw up a machine, although the code would still need to be written with an eye to being used in kernel space. For much of the writing and testing, though, you'd be in a more predictable environment.

The second-most common use would be for proprietary closed-source drivers to be written for userspace. Writing them for the kernel is problematic as the kernel internals change too much, and many such companies spend so little on maintenance that the drivers rapidly become obsolete - requiring users to either use inferior kernels or different technology, with the latter often not being possible or practical. I don't imagine older Linux drivers to be ported this way, any more than they've been maintained by the pathetic commercial vendors who pull such stunts, but newer such drivers should now be less pathetic and marginally more portable, which will be good.

Oh, wrt comments by others, Linux should absolutely never become a microkernel. Message-passing as a methodology is barely adequate for networks - RPC and CORBA are hardly famed for their elegance or performance, and when was the last time you saw Globus or MPI being used to link machines in a LAN gaming session? For that matter, STREAMS has been available for Linux since about Linux 1.2, if I recall correctly. I can't think of a single driver - even outside any of the standard or experimental trees - that uses it. I like the idea of such a patch, as I like the idea of maximum flexibility, but if it were truly useful, it would be used. It isn't.

Linus the pragmatist

[Zork the Almighty]

Maybe this path will ultimately bring proprietary drivers to Linux in force, but I think Linus has made the right decision. We should start looking for other ways to convince companies to write open, GPL drivers.

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.

Re:Like QNX, although not as clean

[wellingj]

http://www.osadl.org/UIO.uio.0.html

They impression that I get is that this is in order to use SOC's more effectively. Things like using PWM and GPIO on SOC's aren't that portable across different brands of micros. This would be an easy way for all the SOC chip makers (Freescale, Atmel, Renesas, Marvell, ect...) to create the bottom level of the driver and use the same userspace driver for embedded developers. this will still give the developers enough leway to mess with things if they need to.
I could be totally off though...

Embrace, Extend, Extinguish

[DriftingDutchman]

If this brings us closer to using (possibly unreliable) windows drivers, a major reason for using windows will be gone.

High time!

[iamacat]

Just because some code controls a piece of hardware doesn't mean that a runaway pointer in it should cause a panic or even corrupt files by messing up filesystem buffers. This will also enable device drivers to make use of all available userspace libraries, with sophisticated algorithms that would never be used if all code had to be written from scratch and non-pagable.

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?

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

[wwahammy]

And its a shame because there are positive things happening at Microsoft and there are negative things just like there are positive and negative things in the Linux world and so forth. Open-source developers, like a scientist, need to put aside egos and see what works and what doesn't, no matter who came up with it.

Not high performance

[eclectro]

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.

Re:Not high performance

[Tony Hoyle]

USB drivers for example. There's no reason for anything using USB to be in kernel space - it just doesn't need the performance.

Ditto for filesystem drivers, although performance matters there - you'd have to design the driver API to minimise context switching.

I don't think anyone's expecting userspace IDE or graphics drivers.

Re:Not high performance

[TheRaven64]

Safe DMA will be possible in the relatively near future. Modern systems are starting to include an IOMMU, which makes this simpler; you simply set up a mapping so the device can only write to or read from the process's address space, and then it can do any DMA it wants safely. Current AMD chips include something called the 'Device Exclusion Vector'. This isn't a full IOMMU, since it doesn't handle translation, but it does do protection. You can tell the DMA controller that the device is only allowed to access a certain block of memory, and DMAs will fail if they write outside this area. The userspace driver would still need to know about machine addresses, rather than vertical addresses. I would probably do this by having a special process type for drivers that had a 1:1 virtual to physical address mapping, and just had holes in its address space where the kernel and other processes were living. The process could just walk its own page tables to do this, but it would be more expensive.

It would be nice to get a stable and usable userspace driver API, since then other operating systems could use it. DRI has done a lot for getting 3D supported across *NIX variants; the Linux and FreeBSD drivers are almost identical, and just need a slightly different kernel module which handles the very low-level parts.

Re:Not high performance

[networkBoy]

Also worthy to note,
USB is framed data and half duplex, while firewire (IIRC) is streamed and full duplex.
I implemented a 4 way mesh in fire wire (4 PCs each with one 4 port firewire NIC) It rocked. Now I have GigE, but still it was awesome, full non-blocking access from any PC to any PC.
-nB

Re:Damnit...

[moro_666]

2.6.20 ? dude !!!

I know i'm hopelessy outdated and my machine shows:

martin@hope ~ $ uname -a
Linux hope 2.6.21-gentoo-r4 #1 Sat Jul 21 22:18:42 EEST 2007 i686 AMD Turion(tm) 64 Mobile Technology MT-30 AuthenticAMD GNU/Linux

Remove that gentoo notice quickly from your slashdot sig. A man using kernel 0.0.02 versions old is a stable version pimp not a gentoo roller... :p

As for the article :D
  Userspace drivers are not really a new groundbreaking idea now are they :D The lists are full of different proposals and attempts over different times, but it's really nice to see that this thing finally got rolling, this may open a lot of closed-source drivers for usage for linux people (a lot of those fancy windows toys).

  Thumbs up Linus ;)

microkernel

[jb.cancer]

well i remember Linus comparing microkernels to 'masturbating' sometime back. It seems as h/w continues to grow in power and several other factors contributing, pushing more stuff to userspace will now look a better idea after all.

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:Useless API, for simple drivers only

[wellingj]

But it does help embedded developers who need access to an SOC's hardware like PWM and GPIO and A2D.
A lot of people really are missing the point here that this patch really doesn't do much for x86, but
does great things for SuperH PPC and ARM.

Sorry not for MS Windows or OS X

[mrnick]

Since this is GPL then neither MS or Apple would dare touch it. If it was BSD then it might be possible that Apple might adopt it but they are not going to put something into their kernel that they don't own. The same goes for MS with the added difficulty of their operating system not being POSIX compliant.

This is why I am prefer BSD license over GPL. Though, I am sure the majority of the readers on here would disagree with me. Anytime I look at open software I always check if there is a BSD licensed equivalent as compared to GPL. Just in case I want to develop it into a commercial application and all. That way I don't have to distribute a license that passes rights onto the users. I can simply take the BSD license version make my modifications and slap a (C) on it. I know the GPL advocates would argue that is what makes GPL good, keeping people like me from doing just that but Apple and MS are people like me. That is why Darwin was derived from BSD not because they were so hot on the Mach kernel but because of it's license. If MS ever goes to a POSIX based UNIX type OS with a Windows GUI, just like Apple did, they would do the same thing but they wouldn't be nice enough to maintain an open source version like Apple has done with Darwin.

My 2 cents and change!

Nick Powers

Re:Sorry not for MS Windows or OS X

[SanityInAnarchy]

This is why I am prefer BSD license over GPL.

This is why I am prefer people who bother to learn English grammar.

Since this is GPL then neither MS or Apple would dare touch it.

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.

Anytime I look at open software I always check if there is a BSD licensed equivalent as compared to GPL. Just in case I want to develop it into a commercial application and all.

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?

I know the GPL advocates would argue that is what makes GPL good, keeping people like me from doing just that but Apple and MS are people like me.

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?

That is why Darwin was derived from BSD not because they were so hot on the Mach kernel but because of it's license.

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.

If MS ever goes to a POSIX based UNIX type OS with a Windows GUI, just like Apple did, they would do the same thing but they wouldn't be nice enough to maintain an open source version like Apple has done with Darwin.

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.

Re:Sorry not for MS Windows or OS X

[drinkypoo]

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?

That's an easy one - when it's more important to you that the world use your implementation than that you get credit and/or other rewards for it.

Examples include the BSD TCP/IP stack, which was rumored to have been incorporated into Windows in, I believe, Windows 2000. It's quite believable because at this time Windows' stack became much faster and more mature, basically overnight. Vista, as you may know, has an all-new stack in which Microsoft reproduced several bugs from antiquity (Vista RC was susceptible, for example, to the LAND DOS attack. Just pathetic. But that's what you expect from Microsoft.

Basically, the BSD license is used for altruistic releases by people who don't believe all software needs to be Free (-as-in-GPL.) Whereas the GPL license is used by people who believe that it does.

In summary, there is no reason why YOU should be BSD-licensing. But there's ample reasons for others to do so.

Re:Performance

[xeoron]

With the new kernel scheduler and, now, the userland api, things are starting to get a lot more interesting...

Re:It's about cloning

[Dan Ost]

The demand for linux drivers needs to reach the point at which a given manufacturer perceives that whatever IP they might expose by releasing Linux drivers is less of an impact than losing out on those sales. We are almost certainly at that point already, but most manufacturers don't realize it.

I was under the impression that Linux had less than 2% of the desktop market. Is that really enough computers to sway the decision making of hardware manufacturers?

Re:Once again...

[Garridan]

Yes. The moderator guidelines suggest that you read newest posts first.

Re:Tail Light Chasing!

[Ripsnorter]

No you don't get how things work around here, when Microsoft does something it is bad. When Linus does something similar it is good.