Slashdot Mirror
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.'"
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.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
And all they would ask is permanent access to the intellectual property of the company. A pittance indeed for a technology company.
Slashdot - where whining about luck is the new way to make the world you want.
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.
Don't thank God, thank a doctor!
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.