Moving Linux Kernel Drivers To User-Space? Nope.

[Ex-Cyber]

I think the evaluation partly depends on what is meant by "driver". A real, actual hardware driver probably gains very little by moving to userspace, for reasons already mentioned. "Drivers" that are really just implementing data-driven abstractions (e.g. filesystems), or talk over a standardized protocol to hardware outside the address space (e.g. most USB device drivers), arguably belong in user space. Still, there are a lot of practicalities to consider, even assuming that the performance hits would be acceptable (If the root filesystem driver crashes, where do you reload it from? How do you negotiate critical sections for atomic operations? etc.).

Also, the "security" angle is shortsighted. A kernel-mode compromise is necessarily a serious breach, but the reverse is not even remotely true.

Short answer: if you want MINIX 3, you know where to find it.

[?John?]

DRI2 versus WDDM

The Win7 graphics architecture split between kernel and userspace is very similar to the one now in linux.

Not to mention right, because at least as far as monolithic kernel designs are concerned memory management, scheduling and power management belongs in the kernel. This is exactly what the DRM modules currently do - they manage GPUs memory and power state. Scheduling is still a work in progress, because it doesn't make any sense for running a single GPU intensive task at a time and can be tackled later in a completely generic way.
And by the way - our current design predates WDDM.

[RealNC]

Btw, this is not about graphics drivers, which is what people in this thread have assumed. Even if the kernel devs decided to move drivers to userspace, graphics drivers would probably still remain in kernel space, since performance is crucial for them.

The core issue affects all drivers (ethernet, disk controller, chipset, etc.) For example, if you have a server and its ethernet driver goes to nirvana, if it's in user space, the kernel can kill it and reload it. This avoids all downtime. As for safety, a bug in the ethernet driver (or any other driver) could give user-space full or partial access to internal kernel structures, or even allow for code execution.

My personal view on this: I don't give a crap :-/

[Zapitron]

You can't take advantage of userspace drivers, or else Tanenbaum wins!

[mrugiero]

Also, the newer WDDM allows video drivers to be installed and updated with reboot

I think you mean without reboot. Else, there's nothing new :lol:

[DeepDayze]

I agree, and I like that because Windows will pop-up a notification that a driver has crashed and then restarts the driver.. In Linux graphics driver crashes more often than not freeze the whole PC solid.. Sure, the driver crashes might be due to a hardware fault, but at least Windows tells you what hardware is failing (at least with graphics drivers and USB devices) while Linux generally does not.

I'd think a "A USB device attached to the system has malfunctioned" or "the graphics hardware has stopped responding and has been reset" kind of messaging to the user would go a long way.

Yes or if you are not in X you'd want to see something like a BUG message in the syslog stating that "driver foo has failed due to error and a restart has been attempted" followed by a traceback snippet. From that snippet you can get an idea of what device or driver is acting up.

True, when drivers crash they lock the machine hard as drivers ARE PART of the kernel

[89c51]

might be a stupid question but anyway...


is it technically feasible to kill and resurrect a driver in the kernel (similar to the Win7 behavior you describe)??

[smitty3268]

might be a stupid question but anyway...


is it technically feasible to kill and resurrect a driver in the kernel (similar to the Win7 behavior you describe)??

There are some things you can do - such as detecting when the hardware or the driver is in a bad state, and resetting it. But in general, if there is a bug in the kernel driver that will cause the kernel to crash then there isn't much that can be done.

Win7 has the same problem, by the way. The behavior talked about where it recovers from a crash is the kernel noticing that the userspace portion has crashed, and restarting it. You could do the exact same thing on linux, only: it would take a lot of manpower/code to get this working properly, and X + GTK/Qt aren't setup to recover properly even if you did restart the userspace driver. It will be much more feasible to accomplish with Wayland.

[China_Guy]

Moving drivers in user-space is a horrible idea, I don't want latency or a slow experience. Better fix the driver issues.

That's why users should ALWAYS report bugs, and developers/users should fix them.

Damn it.

Totally agree,user-space drivers is stupid idea, Linux MUST BE highest performance and avoid context switch, and because it's opensource, we can fix anything!

[kraftman]

You can't take advantage of userspace drivers, or else Tanenbaum wins!

What does this have to microkernels? It just reminds Tanenbaum's bullshit, because you will end with more overhead, less security - stable api. Like some people pointed you can do the same with Wayland without sacrificing anything.