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

[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

[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

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

Full circle?

[MichaelSmith]

Perhaps in ten years time Linux will be a microkernel

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.