Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux Kernel To Have Stable Userspace Drive

Zonk posted more than 7 years ago | from the users-are-the-future dept.

Programming 309

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

cancel ×

309 comments

Sorry! There are no comments related to the filter you selected.

Damnit... (-1, Redundant)

corychristison (951993) | more than 7 years ago | (#19943747)

... just as I compiled 2.6.20!
;-)

Re:Damnit... (1)

Ohreally_factor (593551) | more than 7 years ago | (#19944047)

I think someone needs a nap. =)

Re:Damnit... (1)

adamofgreyskull (640712) | more than 7 years ago | (#19944523)

I think someone needs to install git! 2.6.20? psssh.

Re:Damnit... (2, Interesting)

moro_666 (414422) | more than 7 years ago | (#19944069)

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

Re:Damnit... (1)

rolfc (842110) | more than 7 years ago | (#19944581)

Linux esperto 2.6.22-8-generic #1 SMP Thu Jul 12 15:59:45 GMT 2007 i686 GNU/Linux Ubuntu user, One who only compile when he need it.

Better drivers and more of them (4, Insightful)

Billly Gates (198444) | more than 7 years ago | (#19943751)

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 (0)

Ice.Saoshyant (993846) | more than 7 years ago | (#19943787)

Windows' drivers are on userspace. That doesn't make it any easier to port them to Linux. 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.

Re:Better drivers and more of them (4, Insightful)

whomeyup (635503) | more than 7 years ago | (#19943881)

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 (2, Interesting)

ozmanjusri (601766) | more than 7 years ago | (#19943893)

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 [sourceforge.net] .

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 (1)

sumdumass (711423) | more than 7 years ago | (#19943901)

The point wasn't really that the driver would be portable now but could they be in the future. It is just that they would be more palatable for the manufacturers who wants the stuff to work without open sourcing everything because of some fear or whatever and think that one effort would be a benefit to them.

It also allows the ability for the API calls to mimic some of the windows interface calls which while different in implementation could lessen the learning curve for a company new to the linux game. It could be that with a small kernel driver to compliment or supplement the APIs, the windows driver could work efficiently in linux.

Although I disagree with the GP sentiment that user space drivers is somewhat less valuable then kernel space drivers, It doesn't make a difference where the driver is implemented as long as the same things are achieved at the same efficiency. It doesn't take any longer for something specific like this to happen at user space then it would under Kernel space if everything is working correctly. You can have the same amount of speed and reliability in both. And as far as the user is concerned, a lot of things are transparent as to where they are located. However, there is a small subset of things that might require Kernel space implementations. I'm just not sure how that differs from todays implementations.

Re:Better drivers and more of them (5, Funny)

chromatic (9471) | more than 7 years ago | (#19943897)

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 (0, Troll)

heinousjay (683506) | more than 7 years ago | (#19944015)

And all they would ask is permanent access to the intellectual property of the company. A pittance indeed for a technology company.

Re:Better drivers and more of them (5, Insightful)

howlingmadhowie (943150) | more than 7 years ago | (#19944105)

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 (0)

heinousjay (683506) | more than 7 years ago | (#19944141)

I'm sorry, force society into what position? To using a product? I see no force anywhere. Technology is a luxury item not necessary in any way to survive.

Of course, it's awfully easy to take the position that other people's shit should be taken away from the them and handed to me. I just see something morally repugnant about that.

Re:Better drivers and more of them (2, Insightful)

howlingmadhowie (943150) | more than 7 years ago | (#19944195)

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 (2, Interesting)

Anonymous Coward | more than 7 years ago | (#19944527)

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 (1)

sethawoolley (1005201) | more than 7 years ago | (#19944225)

"Of course, it's awfully easy to take the position that other people's shit should be taken away from the them and handed to me. I just see something morally repugnant about that."

You don't want to clean up other people's shit? I can't disagree with you there. Maybe the neoliberals are onto something and I should switch teams. I don't want to clean up other people's shit either.

Re:Better drivers and more of them (1)

sethawoolley (1005201) | more than 7 years ago | (#19944187)

Frankly, I'm just not buying this excuse.

If they have to hide the information in their interfaces between their hardware and software drivers, then their IP in their hardware or their software isn't all that great.

I don't even care about their software drivers. Just give me access to their framebuffer and/or how to drive the hardware and I'll buy your hardware.

Don't and I won't. That's a market reality.

Re:Better drivers and more of them (4, Insightful)

adamofgreyskull (640712) | more than 7 years ago | (#19944551)

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 (1)

howlingmadhowie (943150) | more than 7 years ago | (#19944027)

exactly. the fact that there aren't linux drivers for every piece of hardware does reflect very poorly on the hardware manufacturers. the kernel developers called their bluff on this a while back (as you allude to). it soon became clear that "we only have so many programmers working for us" and "why should we support a niche operating system?" are totally bogus reasons used to spread fud. what the real reason is, i can only speculate, but i'd tip on it having something to do with microsoft.

Re:Better drivers and more of them (1)

Maniac-X (825402) | more than 7 years ago | (#19944159)

It may have something to do with Microshaft, but then again, it could also simply be an aversion to experiment with something that has the possibility of decreasing their overall revenue. I think they're mainly just trying to be as efficient at money-grubbing as possible, at least in some cases.

Re:Better drivers and more of them (1)

kasperd (592156) | more than 7 years ago | (#19943917)

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.
It might help a bit. But for a lot of hardware they are not going to be shipping this driver for Windows. If possible they are going to ship a user mode driver to be able to claim that their hardware works with "every" operating system. And they are going to be shipping a real Windows driver. And "everybody" is going to say Linux performance sucks because Linux only have user mode drivers, where Windows have real kernel drivers. (Of course the same people are going to blame Microsoft for every time the driver crash their system).

Of course for some hardware performance is not all that important. As long as the driver will be locked in memory, it won't matter if something like a keyboard driver was done in user mode. Hell, in recent years lots of hardware have been designed that will require the driver to spend loads of CPU time, because that could shave a few cents of the hardware cost. Such hardware would be slow on any operating system, kernel driver or not.

Embrace, Extend, Extinguish (2, Interesting)

DriftingDutchman (703460) | more than 7 years ago | (#19943949)

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

Re:Better drivers and more of them (1)

Peaker (72084) | more than 7 years ago | (#19943955)

I, for one, am glad that proprietary drivers are so poor, because it encourages free drivers to be written instead.

These are not only free-er, but usually of better quality too.

Re:Better drivers and more of them (1)

Solra Bizna (716281) | more than 7 years ago | (#19944145)

I, for one, am glad that proprietary drivers are so poor, because it encourages free drivers to be written instead.

These are not only free-er, but usually of better quality too.

I'm still waiting for a Free 3D driver for my Radeon 9800 Pro Mac Edition. (Not for much longer, though, since I'm moving to an all-OSX setup on my next computer...)

-:sigma.SB

P.S. no, the R3xx DRI code in the Xorg tree did not work. Not even accelerated 2D.

Not high performance (2, Informative)

eclectro (227083) | more than 7 years ago | (#19944063)

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 (2, Interesting)

Tony Hoyle (11698) | more than 7 years ago | (#19944603)

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:Better drivers and more of them (1)

suv4x4 (956391) | more than 7 years ago | (#19944237)

A stable kernel api for drivers is what linux needs as proprietary driver writers make poor quality and buggy implementations.

You can't have a "stable kernel api for drivers". The kernel might be super stable but since it gives kernel mode access to the drivers, the drivers can still crash the system if poorly written.

That's after all, the entire problem, and why we have userspace drivers. And why Vista has userspace drivers.

Re:Better drivers and more of them (1)

Roydd McWilson (730636) | more than 7 years ago | (#19944323)

Dude, stable in this instance also means does not change with different kernel versions. One of the issues prop devs've had is building a bin driver that loads into arbitrary kernel versions 'n builds. Moreover, with proper type chicken, you c'd p'tentially run crappy drivers inside the kernel at no bigger risk than in user mode.

Re:Better drivers and more of them (1)

suv4x4 (956391) | more than 7 years ago | (#19944385)

Moreover, with proper type chicken, you c'd p'tentially run crappy drivers inside the kernel at no bigger risk than in user mode.

Yea sure, with proper type of glasses everything around you will be pink. You better do a research on why bad code running in ring 0 can always hang the system never mind the API.

Re:Better drivers and more of them (0, Troll)

SanityInAnarchy (655584) | more than 7 years ago | (#19944547)

You better do a research on why bad code running in ring 0 can always hang the system never mind the API.

You'd better do some research on... well, English grammar, first, but also check out systems like Java, Flash, JavaScript, Silverlight (and the rest of .NET), and so on. It is possible to run untrusted code in the same address space as trusted code. It should therefore be possible to run untrusted code in ring 0. Done right, you'd get a performance boost to everything, by running absolutely everything (except legacy apps) in "kernel mode" / ring 0, and no more security risk than you had before.

Yes, I'm aware that a Javascript, for instance, can currently hang the browser, or crash it, or even sometimes get into things it shouldn't be able to (like the user's files). All of this is due to buggy implementations. I think we may have enough practice by now to be able to do this right, if we start from the ground up.

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.

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.

Re:Better drivers and more of them (2)

Roydd McWilson (730636) | more than 7 years ago | (#19944595)

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 (1)

Tony Hoyle (11698) | more than 7 years ago | (#19944613)

Done right, you'd get a performance boost to everything, by running absolutely everything (except legacy apps) in "kernel mode" / ring 0, and no more security risk than you had before.

Seriously dude, read a book on OS design and realize how utterly wrong that statement is.

Sorry not for MS Windows or OS X (2, Insightful)

mrnick (108356) | more than 7 years ago | (#19944261)

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 (1)

Roydd McWilson (730636) | more than 7 years ago | (#19944337)

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.

I don' see the ol' em-dollarsign pullin' that kinda shit veritably soon. They got a lot invested inta vista architectrally, and honestly now, deep down it ain't any worse than unix... it's mostly a matter of dev process suckage, which'd soon enough infect any other code base. But heyo ya know what? Them microfuckers do contribute to at least one total bona fide community open source project: GHC [haskell.org] !! No kiddin, check out the site maint's email addr.

Re:Sorry not for MS Windows or OS X (1)

that this is not und (1026860) | more than 7 years ago | (#19944355)

If MS ever goes to a POSIX based UNIX type OS with a Windows GUI,

POSIX is an api layer. And there is a fairly robust POSIX api readily available for the NT kernel beneath Windows. It can plug in and run in parallel with the Win32 api layer. You can even download it for free. It's presently called Services for UNIX and formerly was called Interix. And Interix was a fully compliant POSIX layer.

Services For Unix even includes the GCC and the gnu toolchain bundled with it.

This POSIX layer is much more than the 'bare minimum' skeleton layer that Microsoft created themselves back in the NT 3 days for 'compliance' purposes. Interix was developed by a non-Microsoft entity (Softway Systems) who had a source license to the NT kernel for that purpose.

Re:Sorry not for MS Windows or OS X (1)

Tony Hoyle (11698) | more than 7 years ago | (#19944637)

Services For Unix even includes the GCC and the gnu toolchain bundled with it.

Actually it doesn't. Vista includes the basic core, but to get any actually commands you have to go to the interix site and download them one by one and it takes bloody ages as there's no installer.

I tried it for a little while and went straight back to cygwin, which installs in minutes, runs a better (SFU has some really wierd interactions with the command shell.. the shell returns immediately instead of waiting for the command, plus it has hopelessly broken cr/lf handling) and is better tested.

Re:Sorry not for MS Windows or OS X (2, Informative)

SanityInAnarchy (655584) | more than 7 years ago | (#19944657)

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:Better drivers and more of them (2, Informative)

SanityInAnarchy (655584) | more than 7 years ago | (#19944597)

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, tech support, bug reporting, and so on, on multiple platforms. I'm convinced that, done right, the costs here could be justified, but I think people get scared away before they actually have any real idea of how much it would cost, especially in the long term.

Wow, lots of posts so far. (n/t) (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#19943755)

(n/t)

Full circle? (5, Insightful)

MichaelSmith (789609) | more than 7 years ago | (#19943769)

Perhaps in ten years time Linux will be a microkernel

Re:Full circle? (1)

Goalie_Ca (584234) | more than 7 years ago | (#19943885)

And the debate [google.com] continues!

Re:Full circle? (5, Funny)

Tumbleweed (3706) | more than 7 years ago | (#19943973)

Microkernels are the wave of the future.

And always will be. :)

Re:Full circle? (1)

giminy (94188) | more than 7 years ago | (#19944045)

I've been thinking the same thing...first FUSE, now this. More and more of the kernel is going into userspace services, and these are the 'biggies.' It's really a welcome change. Albeit a strange one, given the great Torvald/Tanenbaum debate.

Re:Full circle? (1)

diego.viola (1104521) | more than 7 years ago | (#19944205)

I hope it will but I don't want to wait 10 years for that!

Re:Full circle? (1)

Pecisk (688001) | more than 7 years ago | (#19944619)

Linux kernel are usually referenced as _hybrid_ type kernel. For example, Ubuntu and Debian built EVERYTHING they can in modules, so their kernels are more microkernels than monoliths.
But I really doubt that Linux will be pure microkernel sometimes, because...there is no need for it, _IMHO_.

Performance (1)

katterjohn (726348) | more than 7 years ago | (#19943773)

Wouldn't implementing this in userspace drastically lack in performance compared to kernelspace drivers?

Re:Performance (4, Informative)

corychristison (951993) | more than 7 years ago | (#19943791)

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.

Re:Performance (0)

Anonymous Coward | more than 7 years ago | (#19943853)

FTA: "not yet implemented"...

The GP said, "in ten years time". Not quite sure I get your point.

Re:Performance (0)

Anonymous Coward | more than 7 years ago | (#19943887)

Nevermind. Its slashdot's gay new comment system being incompatible with Opera, mixing replies to posts.

Re:Performance (1)

BiggerIsBetter (682164) | more than 7 years ago | (#19944403)

So graphic drivers as well as file system drivers and similar cannot use this API at the moment.
Fuse [sourceforge.net] and NTFS-3G [ntfs-3g.org] seems to work pretty well for me, so I'm not entirely convinced by that statement.

Re:Performance (0)

Anonymous Coward | more than 7 years ago | (#19944427)

Yes, work pretty well as in parts 1 and 2 of "Make it work, make it work well, make it work fast"
They may work, but use a ridiculous amount of CPU power if you're doing serious data transfers....

Re:Performance (4, Insightful)

jd (1658) | more than 7 years ago | (#19943873)

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.

Re:Performance (1)

Verte (1053342) | more than 7 years ago | (#19943999)

That's what, 80,000 cycles plus? That's ridiculous. All to save some registers and load a new LDT?

I agree on the Linux never becoming a microkernel, that would be a really ugly hack. But I think the kernels being developed today, the ones with memory essentially being a first class, sharable resource [such as Coyotos, which IIRC has an interface for sharing address spaces with other processes]. Once shared memory becomes simple and usable, we might see some nice new mk on top.

Re:Performance (1)

Roydd McWilson (730636) | more than 7 years ago | (#19944407)

That's what, 80,000 cycles plus? That's ridiculous. All to save some registers and load a new LDT?

Fo sho 80k cycles is a bitch, but what you screamin' 'bout loadin a new LDT?? Yeah it may happen an' all, but Linux don't give much'f a damn 'bout segments... a couple big 4giggers'll do. The real dope is at the page table... straight up CR3 swappin', and 'course the attendant TLB and cache thrashin' (yeah I know you don' gotta clearance it all out dudez).

Re:Performance (1)

cryptoluddite (658517) | more than 7 years ago | (#19944009)

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?
Uh you realize that anything object oriented is basically equivalent to microkernel? Each object is a separate 'memory space' that only it can affect, and all interaction is through 'messages' aka method invoke + wait.

An operating system would be so much better running a safe language. I program in C every day because of some requirements, and it is so much not a good language for operating systems. Most of what an OS does is manage lots of information and access to it. C is really, really bad at both of those... what it is is fast, but so much time in a system like Linux is wasted doing context switches and from overhead of using really really simplistic interfaces.

Just look at all the contortions libc does to make bare system calls more usable to applications -- and what the OS does to make information available as simple system calls. sys_getpid takes maybe 5 instructions in a 'message passing' safe os, but takes 1500 cycles in linux. Try to find the parent folders given just a file's fd or inode for instance... it's really annoying for no reason other than the system is designed in C and had to be made ridiculously simple because of that.

I mean here we're talking about people writing user-space drivers and filesystems and such for a systems with really really slow context switches -- compared to a kernel running typesafe code. People are doing this thing which is hundreds of times slower than a microkernel that runs a safe os, but speed is so important eigh? Come on.

Re:Performance (1)

Roydd McWilson (730636) | more than 7 years ago | (#19944459)

I mean here we're talking about people writing user-space drivers and filesystems and such for a systems with really really slow context switches -- compared to a kernel running typesafe code. People are doing this thing which is hundreds of times slower than a microkernel that runs a safe os, but speed is so important eigh? Come on.

Amen brotha, sing it!

Total bollocks -- language wars irrelevant (0)

Anonymous Coward | more than 7 years ago | (#19944593)

a systems with really really slow context switches -- compared to a kernel running typesafe code

Type safety does not ensure general operational safety. There are 1001 other sources of trouble in an OS kernel, and a good kernel keeps them all at bay.

The MMU delivers hard protection guarantees that no language can provide, so your focus on type safety just shows lack of understanding of the role of operating systems and context switching.

Linux will decouple and partition to scale (1)

Morgaine (4316) | more than 7 years ago | (#19944489)

> Linux should absolutely never become a microkernel

Religion notwithstanding, it will become microkernel-like, because a monolithic kernel just doesn't scale. It's as simple as that.

Monolithic kernels don't scale as the number of CPUs rises, nor as the number of drivers and other logical components goes up.

Because of the need to scale, in time Linux will partition itself into independent subsystems, and slowly but surely will become a microkernel-type design, because the alternative to that would be to suffer astronomic bug rates from combinatorial complexity explosion and very poor performance from CPU contention compared to a decoupled, decentralized design.

That microkernel future is 100% inevitable, because fighting growth is like trying to sweep back the tide. In due course, the debate will just fade away, and engineering will take over. And engineers always decouple.

Re:Linux will decouple and partition to scale (1)

joib (70841) | more than 7 years ago | (#19944583)


Religion notwithstanding, it will become microkernel-like, because a monolithic kernel just doesn't scale. It's as simple as that.


Nice theory. Unfortunately it seems the kernel developers that are actually working on making Linux scale to NUMA systems with O(10000) processors disagree with you: https://ols2006.108.redhat.com/2007/Reprints/lamet er-Reprint.pdf [redhat.com]

Re:Performance (1)

iamacat (583406) | more than 7 years ago | (#19944053)

Yes, in the same way as running a game or a video authoring application under a time-sharing operating system "drastically lacks in performance". In overwhelming majority of cases, it has been found that stability, ease of maintenance and convenience of using 3rd party libraries with non-trivial algorithms are well worth the not-so-drastic performance penalty. Besides, in userspace you can use pthreads to take advantage of multiple CPUs/cores in todays computers. Writing an explicitly multi-threaded kernel driver is not trivial.

What would be really nice... (0, Troll)

Bonker (243350) | more than 7 years ago | (#19943775)

would be a world where you didn't ever have to RECOM-FUCKING-PILE the kernel to install major drivers.

No, it's not that bad any more, especially in User-oriented distros like Ubuntu. There are quite a few user-space drivers out there, especially for non-hardware related tasks like filesystems (as opposed to disk IO). There are still times when, to get something to work properly, you simply have to recompile the kernel. This is especially true for 'nonstandard' hardware that likes direct IO, like disk-arrays.

Re:What would be really nice... (1)

laptop006 (37721) | more than 7 years ago | (#19943883)

You already don't.

Look at things like debian's module-assistant.

Re:What would be really nice... (1)

pembo13 (770295) | more than 7 years ago | (#19944061)

I thought all you need are the kernel headers and you just compile (not recompile) the module alone.

Re:What would be really nice... (0)

Anonymous Coward | more than 7 years ago | (#19944077)

You don't know what you are talking about!
Drivers can be compiled as modules for many, many years already. And modules can be put in an initrd to load a driver for the root filesystem during boot.
So there is no need at all to recompile the kernel. Maybe you have been doing it all the time, but that is ignorance. Blame yourself, not Linux.

Re:What would be really nice... (1)

Alioth (221270) | more than 7 years ago | (#19944179)

You've not needed to RECOM-FUCKING-PILE the kernel for a new driver for well over 10 years now... I think modules were added back in 1993 or so. The only people who've been recompiling kernels in the last decade are either (a) unaware of modules or (b) building a statically linked kernel for a niche app. Or perhaps some vendor was too clueless to supply a driver as a module.

Re:What would be really nice... (1)

Arkan (24212) | more than 7 years ago | (#19944255)

> (...)'nonstandard' hardware that likes direct IO, like disk-arrays.
Which is, as far as I know, scarcely used in a small business situation, or even a home user one. And in this kind of situation, you have system administrators - I know, I'm one of those - who are PAID to do this kind of job.
Not that recompiling a kernel really requires high level expertise, mind you.

Anyway, isn't the solution to petition your favorite vendor to provide the relevant driver with a convenient licence so that it can be incorporated in the kernel?

--
Arkan

I thought I read Uberspace (4, Funny)

TheRistoman (1062158) | more than 7 years ago | (#19943781)

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

Re:I thought I read Uberspace (1)

Romwell (873455) | more than 7 years ago | (#19944199)

I was just about to ask if I'm the only one who read Uberspace Drive (which is sorta like Warp Drive, only cooler), but in spite of Slashdot instinct, I searched the thread first =) Pleeeeeeeeeasse mod parent up =)

What exactly are the API stability guarantees? (0)

Anonymous Coward | more than 7 years ago | (#19943825)

A stable API is great because it means that code written against it will continue to work for future versions of the kernel.

Out of curiousity, what is the guarantee (or intention)? Is it expected that API won't change again for 2.6, or is it more "we're going to try really hard not to change it unless we have to" kind of thing?

Re:What exactly are the API stability guarantees? (0)

Anonymous Coward | more than 7 years ago | (#19943877)

You're completely missing the point.

The Userspace-API of linux was and will probably continue to be ultrastable. With the right libc you can run a programm written for Linux0.99 on Linux2.6.22.

What is changing and will continue to change is the in-kernel-driver-API. So nothing new here.

The news: A driver API _in_Userspace_.

Capis?

Re:What exactly are the API stability guarantees? (1)

phantomlord (38815) | more than 7 years ago | (#19943903)

Out of curiousity, what is the guarantee (or intention)? Is it expected that API won't change again for 2.6, or is it more "we're going to try really hard not to change it unless we have to" kind of thing?
Given that Linus usually has a fit when someone breaks userspace (but generally doesn't mind breaking kernelspace, as long as the affected code is patched at the same time), I'd say it's going to be more along the lines of "we're going to try really hard not to change it unless we have to." Even then, it's typical to see an "emulate OSS devices under ALSA?" type option.

Finally... (3, Insightful)

Statecraftsman (718862) | more than 7 years ago | (#19943851)

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

Verte (1053342) | more than 7 years ago | (#19944067)

Although your post is cute, you actually have a point. You can argue about how changes to the kernel affect performance, but otherwise they aren't likely to make a difference to the GNU/Linux experience. Maybe we should be actively pointing our developer friends away from romantic dreams of kernel hacking and on to more overlooked projects. Or even wine..

Re:Finally... (2, Insightful)

zullnero (833754) | more than 7 years ago | (#19944093)

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

howlingmadhowie (943150) | more than 7 years ago | (#19944175)

no, the major blocker is "it's not windows"

Re:Finally... (0)

Anonymous Coward | more than 7 years ago | (#19944245)

Considering that the major blocker for the average person in regards to making the switch to Linux happens to be driver support
no, the major blocker is "it's not windows"
You're both right. It's easy to get Windows drivers for my hardware: download, click "install". On Linux, getting updated drivers means recompiling a kernel; grandma / soccer mom can't do that.

Re:Finally... (2, Informative)

howlingmadhowie (943150) | more than 7 years ago | (#19944485)

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

Linus the pragmatist (2)

Zork the Almighty (599344) | more than 7 years ago | (#19943905)

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.

Re:Linus the pragmatist (1)

Alioth (221270) | more than 7 years ago | (#19944193)

It's not just proprietary drivers, it's open source ones too, especially for niche hardware. You're never going to get your kernel driver accepted by the high priests of the Linux kernel team for a piece of hardware with half a dozen users, so you are doomed to rebuilding the module every time you do a yum update, and your distro has a new point version of a kernel. It really kills the usability of Linux when this happens.

Fortunately, for USB devices, this has existed for a while. (Indeed, there's little reason to write a kernel-land USB driver these days).

Here's a better idea (0)

Anonymous Coward | more than 7 years ago | (#19943909)

Design an API that will be transparent to the execution context. Drivers that are proven to be stable over time can be moved from user space to kernel space at the flick of a root command (no re-compilation of driver code or adaptation required).

Re:Here's a better idea (0, Flamebait)

wellingj (1030460) | more than 7 years ago | (#19943953)

No one is stopping you from implementing it yourself and submitting it to the main line.

Like QNX, although not as clean (3, Informative)

Animats (122034) | more than 7 years ago | (#19943915)

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. [embedded-c...europe.com]

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 (2, Informative)

wellingj (1030460) | more than 7 years ago | (#19944055)

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

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

Poor compromise (1)

yvajj (970228) | more than 7 years ago | (#19943967)

I wonder if this compromise is worth it. I'd much rather have stable kernel drivers than unstable userspace drivers.

If a driver is buggy and in userspace, its possible that the system could recover from the error, however you could still end up in some unstable state that would potentially end up requiring a reboot (depending on the driver in question).

Also, there is a higher cost of running a driver in userspace (ring 3) than kernel space (ring 0). As mentioned by the article, high traffic drivers (requiring DMA) are not supported.

The reasoning for this seems to be due to unstable proprietary kernel drivers. IMO, the solution to solving this problem is driver signing and certification. Don't use a driver unless its been signed and certified.

Re:Poor compromise (1)

Solra Bizna (716281) | more than 7 years ago | (#19944437)

The reasoning for this seems to be due to unstable proprietary kernel drivers.

What about unstable open source kernel drivers?

-:sigma.SB (who went through over 60 reboots trying to get non-crashing 3D on his iBook's Rage 128 before finally giving up)

High time! (2, Interesting)

iamacat (583406) | more than 7 years ago | (#19944007)

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) (5, Informative)

AlphaWolf_HK (692722) | more than 7 years ago | (#19944037)

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) (3, Informative)

Anonymous Coward | more than 7 years ago | (#19944081)

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) (4, Informative)

wwahammy (765566) | more than 7 years ago | (#19944211)

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) (1)

AlphaWolf_HK (692722) | more than 7 years ago | (#19944497)

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? Well, this is slashdot. This is the reason I had to emphasize heavily that I am not trying to troll here. I've had it happen more than once where I've said something positive about Microsoft and immediately get modded down as trolling.

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

wwahammy (765566) | more than 7 years ago | (#19944567)

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.

microkernel (2, Funny)

jb.cancer (905806) | more than 7 years ago | (#19944097)

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.

Re:microkernel (1)

diego.viola (1104521) | more than 7 years ago | (#19944505)

Yeah I hope to see this in the future, a modern Linux micro-kernel with all the cool features and message-passing.

Useless API, for simple drivers only (3, Informative)

kscguru (551278) | more than 7 years ago | (#19944171)

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 (4, Informative)

suv4x4 (956391) | more than 7 years ago | (#19944545)

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.

General or specific API? (1)

ettlz (639203) | more than 7 years ago | (#19944557)

This seems to be an on-going trend in the kernel: FUSE, libusb, libraw1394 and ALSA all (to a certain extent) export what were traditionally kernel-bound services/drivers to user-space, while leaving the minimum necessary kernel-side mechanism, such as VFS redirection, and low-level I/O and interrupt handling. However they all do this in different ways according to the needs of the hardware. So while a generic API may be a good for unusual pieces of hardware, might it not be a good idea to develop application-specific subsystems that hook the kernel's existing ABIs (as used by current kernel-space drivers)? For example, we could have something specific for networking devices that does all the necessary set-up on the kernel side (establishing device name, wireless extensions, etc.) and communicates with a user-space driver (a bit like ALSA), which could be anything from a specific Free-Software driver to a proprietary modem driver or a wrapper for something like NDIS. Similarly with network protocols, although this might look more like FUSE.

time to switch to another OS (0, Troll)

dltaylor (7510) | more than 7 years ago | (#19944573)

this has always been is an incredibly brain-damaged concept on several bases.

drivers are hard to write for a reason. they require a detailed understanding of the physical actions of the device being driven (does it interrupt, and if so, under what circumstances, and how is the interrupt from the device mapped to the CPU(s), for example, or, if it does DMA/memory mastering, what are its limitations such as alignment) and what amounts to an embedded operating environment, with necessarily very different abilities and restrictions. while there are features in the kernel to map common features with different implementations, such as managed memory, to regularize the implementations, those features have little in common with the needs of user-space applications. devices are asynchronous from the CPU in ways that user-space applications can never be. the few people who write drivers well have a different view of the system than application programmers, regardless of their competence, and even many of the best of the latter are utterly incapable of the former (and vice-versa, sometimes).

the loss of security means that Linux is headed the way of M$-Windows, which can never be secured, short of unplugging the power lead. the blurring of boundaries in the cause of "ease of use" is completely contradictory to good security practice. remember the DX9 "bug" that allowed execution of properly crafted DirectMusic streams. welcome that to the Linux world when this idiocy spreads.

thirdly, this will mean even less ability to get information from device manufacturers that would enable us to create secure and fast drivers. Linux will become a bog-slow piece of junk burdened with crapware written by programmers who have every disincentive to craft good drivers (ones that don't do things like busy-wait for ridiculously long periods). after all, once Linux is bogged down worse than M$-Windows, all the companies have to say is "it's Linux' fault; our Windows drivers work just fine, so use that".

the comment about application programmers not making the transition to driver programming is based on extensive personal observation (decades across multiple companies). very few schools teach anything like the theory, much less require the practice, of understanding how hardware works, so they simply don't know how. most hardware companies don't charge for the device drivers, so they see that as purely a cost burden, and therefore don't have any incentive to have good in-house training. when I've watched application-trained programmers try to write drivers, they don't actually think in terms of the physical time and sequence in which device events occur, and then spend ridiculous amounts of effort trying to "tune" that improperly designed code, which of course breaks with every little change in the platform.

BTW, not all driver writers make good decisions all of the time, either. some idiot decided to piss away CPU cycles shifting the SCSI STATUS byte returned for every transaction, for example.

About time (1)

DrXym (126579) | more than 7 years ago | (#19944575)

Linux needs a stable ABI for drivers. Insisting that vendors release drivers for every dist, or that they open source their code is unrealistic. Open source is obviously desirable but it's still not much to end users who wouldn't have a clue how to build it.

It would be great if dists would support an ABI and produce some dist neutral packaging system that allowed drivers to be installed / uninstalled easily by mere mortals no matter what dist they had.

Those that don't know Plan 9 (1)

DrSkwid (118965) | more than 7 years ago | (#19944677)

Are doomed.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?