Device drivers commonly execute in the kernel to achieve high performance and easy access to kernel services. However, this comes at the price of decreased reliability and increased programming difficulty. Driver programmers are unable to use user-mode development tools and must instead use cumbersome kernel tools. Faults in kernel drivers can cause the entire operating system to crash. User-mode drivers have long been seen as a solution to this problem, but suffer from either poor performance or new interfaces that require a rewrite of existing drivers.
This paper introduces the Microdrivers architecture that achieves high performance and compatibility by leaving critical path code in the kernel and moving the rest of the driver code to a user-mode process. This allows data-handling operations critical to I/O performance to run at full speed, while management operations such as initialization and configuration run at reduced speed in user-level. To achieve compatibility, we present DriverSlicer, a tool that splits existing kernel drivers into a kernel-level component and a user-level component using a small number of programmer annotations. Experiments show that as much as 65% of driver code can be removed from the kernel without affecting common-case performance, and that only 1-6 percent of the code requires annotations.
(Score: 4, Touché) by Gravis on Sunday November 15 2015, @07:21PM
... systemd could absorb all user-mode drivers. ;)
(Score: 2) by sjames on Thursday November 19 2015, @04:58PM
There's a picture of systemd in it's natural state here [nocookie.net].
(Score: 2) by Zz9zZ on Sunday November 15 2015, @07:32PM
This seems like a good thing, allowing compartmentalization. However, could this introduce a pathway for user level programs to access critical kernel operations?
~Tilting at windmills~
(Score: 2) by maxwell demon on Sunday November 15 2015, @11:10PM
I guess such drivers would still need to run as root. If you are root, you already have such a pathway: Just load a kernel module.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Insightful) by Gravis on Sunday November 15 2015, @07:43PM
if you are using a user space driver then it's unlikely to be anything critical therefore speed is beside the point. if you need speed, write a damn kernel driver! if your code is too unwieldy/flawed to put in the kernel then you have an entirely different problem.
(Score: 2, Interesting) by TheRaven on Sunday November 15 2015, @08:57PM
Oh, and for anyone not paying attention, TFA is a paper from ASPLOS 2008: it's probably getting close to deserving a test-of-time award in the next couple of years, because it's fairly accurately predicted what everyone is is doing now, for places where performance matters.
sudo mod me up
(Score: 1, Troll) by Gravis on Sunday November 15 2015, @09:34PM
Modern GPU drivers do memory allocation and IOMMU setup in the kernel and then do everything else entirely in userspace to achieve maximum performance.
so basically they act as interfaces to the hardware? isn't that the definition of a driver?
If you want to go fast, you don't want the kernel in the way
LOL! right because the kernel is so restrictive, eh? xD
not bothering with the rest of your message because what you wrote indicates you are out of your depth.
(Score: 3, Interesting) by TheRaven on Monday November 16 2015, @06:08PM
so basically they act as interfaces to the hardware? isn't that the definition of a driver?
No, that's not the usual definition. Drivers are both interfaces and abstractions. A SATA disk driver doesn't just give a SATA command queue to the rest of the system, it exposes something that stores and retrieves blocks (and provides other functionality) and exposes an interface to the next layer in the stack that's the same as SAS or other disk interfaces.
LOL! right because the kernel is so restrictive, eh? xD
Yes, the kernel provides a load of abstraction that handles the generic case well. It abstracts all of the network transport specific details behind the socket interface, for example. That's great if you want code that doesn't have to care about these things, but if you want code that runs a subset of UDP or TCP really fast then having that code all get out of the way and let you push packets into the device rings directly is going to be a lot faster.
not bothering with the rest of your message because what you wrote indicates you are out of your depth.
Don't read my message then, go and look at how modern GPU drivers work (I've worked on some in the past) or read some of the recent SOSP papers. For example, compare the performance of Namestorm to BIND and then look at why Namestorm is faster (read the paper).
Or, you know, argue with some real examples. I can back up everything that I've said with shipping code in production systems and with papers in top-tier operating system venues. You can back up what you've said with... what exactly?
sudo mod me up
(Score: 3, Interesting) by turgid on Sunday November 15 2015, @08:03PM
In my day, we had microkernels [wikipedia.org]. I thought we already had driver architectures where most of it was in user-space but the important driver-y bits were in the kernel, like FUSE [wikipedia.org]?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Sunday November 15 2015, @08:04PM
Been this way for years on real OS on REAL HARDWARE (main frames). I been writing this way since the 80's from my first C code on an IBM XT..
Who is still doing it wrong?
(Score: 2, Insightful) by jimtheowl on Sunday November 15 2015, @10:08PM
Mainframes are one thing, but what do you mean by 'that way' on an IBM XT.
On DOS?
(Score: 2) by fishybell on Sunday November 15 2015, @08:23PM
I'm all for the programmer designing drivers to work in both user-space and kernel-space. The last time I wrote kernel drivers I explicitly left only timing-related and hardware-related code in kernel-space and used one the many [wikipedia.org] interfaces to facilitate communication between the various blocks of logic. The user-space ran user provided logic, and the kernel carried out the specifics. It seemed painfully obvious to me to separate the code like that.
So what does this approach provide? An automated process to split up a driver based on assumptions and hints (annotations). I love automated code generation, but I'm not sure the kernel is the best place for it. This seems like a great way to introduce bugs for programmers that can't or won't separate their code manually.
(Score: 2) by MostCynical on Sunday November 15 2015, @09:57PM
aiming for 6% of the code to be annotated seems a little optimistic.
"I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
(Score: 3, Insightful) by JoeMerchant on Sunday November 15 2015, @11:41PM
>and must instead use cumbersome kernel tools.
So, is it just not worth developing better kernel tools - or an adaptation path so that some userspace features can be applied in the kernel? How about debugging the kernel inside (or from) a VM?
Is there some counter-incentive to development of better kernel tools? User space tools have come a long way in the next 10 years, seems like there should be some spillover by now.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end