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

[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

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

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

[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

[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

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

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

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

Re:Performance

[xeoron]

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