Moving Linux Kernel Drivers To User-Space? Nope.

[Sidicas]

Something like recovery from a driver failure should be a feature that the Linux kernel should have and decoupling drivers from the kernel should theoretically allow the kernel to attempt a "restart" a driver that has crashed/segfaulted due to bugs or hw faults and put a notification into the system log of that action.

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.

[pmorph]

The main advantage of having video drivers in user space is that neither software nor hardware faults in the video system can cause the kernel to hang -- at worst the process will hang, and the kernel can terminate it. I think Windows Vista and onwards do something like this..

I've always wondered how this would actually work.. Like, would it be possible to save the X session, if an application run from that session crashed the vid driver, or would you need to restart the X server too?

[kraftman]

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.

Exactly. It seems it's terrible idea:

https://lkml.org/lkml/2012/2/24/338

https://lkml.org/lkml/2012/2/24/253

Tanenbaum retro... and another sensational article at Phoronix.

[liam]

The main advantage of having video drivers in user space is that neither software nor hardware faults in the video system can cause the kernel to hang -- at worst the process will hang, and the kernel can terminate it. I think Windows Vista and onwards do something like this.

The problem is that you need a carefully designed interface, which is a bit hard to jerry-rig into something like the Linux kernel at this point. You'll also take a considerable performance penalty, and maintaining the interface will be a pain.

In terms of security, I see very little or no benefit -- if you can't trust your video driver, you're hosed anyway, since it can present anything to the user to trick them into doing whatever.

Therefore, I think the main benefit is stability.

A preempt kernel should be able to kill misbehaving kernel threads.

[orome]

I like the idea

may be it's because i contribute to ukernel OS in my free time, but I think having a possibility of uspace drivers would be great.

most devices use memory mapped registers and those are accessible in uspace without any problems, problems appear when you consider handling interrupts (you cannot disable interrupts without privileged access, thus you need a small piece of code to run in kernel while the interrupts are disabled), but as linux has a mechanism for threaded interrupts it's nothing that can not be solved.

of course there are drivers that are more suitable for this design than others, USB drivers and input drivers are the best candidates. I don't think that anyone would be able to notice any overhead (there is MUCH more overhead getting the action to appear on user screen than there would be controlling a device), on the other hand anyone who has seen USB HID specs should be scared to see its implementation having access to kernel memory (and there are more complicated devices).

problem with devices controlled from userspace is that kernel can't use it (not in a nice way), that was the case with X, if you wanted something to appear on the screen without telling X you need ask X to surrender the device so that you can control it yourself, configure it and then display, surrender it again and tell X to reclaim it (hence the blinking when switching to consoles and back). Thus if kernel wants to output something nice (like BSOD) it needs to tell X or risk weird stuff when accessing the device (garbled screen, text mode over graphics,...)

it's true that bugs are better fixed, but a bugfree system is an utopia, and damage containment is not a bad idea.
For all those ppl that hate ukernel design and think that it's an unsuitable for modern use remeber that the OSes that reach high EAL levels are ukernels.

[elanthis]

How could device drivers be moved outside kernel space?
It sounds a bit silly to me, then there should be an interface to give full access to hardware directly from userspace, then it would be even nastier than having some badly programmed drivers.

Windows 7 does this for its video drivers (and others). There are plenty of advantages. One of the primary reasons that Windows 7 barely ever crashes is this very thing, in fact. Microsoft found that over 95% of BSOD's in WinXP and earlier were video driver related. On a similar note, I've had Linux kernel-oops on me quite a few times in the last year, all of which are DRI/DRM/KMS related. Also, the newer WDDM allows video drivers to be installed and updated with reboot, allows video driver crashes to be gracefully handled (your screen goes black and then resets, and most apps don't notice or care; even most well-written games will survive it just fine). Meanwhile the Linux in-kernel model means you have to patch kernels and rebuild half your low-level OS just to get a simple driver fix in, which is nothing short of retarded, and incredibly user-hostile.

The hardware interface is easy to deal with, and Linux already has a means for doing it with various other user-space drivers. There is a small tiny bit of kernel driver (which can even be mostly hardware-agnostic and data-driven) that just sets up the port access and I/O ranges for the userspace driver (which need not run as root, but also should not run as any old user, but rather as an unprivileged system user).

There is a small bit of a performance overhead for this, but obviously this is not a problem: nobody in their right mind accuses Windows of being slow at graphics. In the end, I'd much rather have stability and flexibility and user-friendliness than the 2% extra performance that might be had with in-kernel drivers.

[movieman]

Windows 7 does this for its video drivers (and others). There are plenty of advantages. One of the primary reasons that Windows 7 barely ever crashes is this very thing, in fact.

This is probably also why my Window 7 video driver crashes a lot more than the Linux driver.... and I rarely boot the laptop into Windows these days, so in terms of uptime it must be many times less stable than Linux.

[peppepz]

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.

I think we're mixing "GPU hang" with "driver crash". Linux drivers do reset the GPU when it stops executing commands, as Windows does (you get a line in the kernel log instead of a pop-up menu).
If the memory management part of the driver (which has to be kernel mode) crashes, this will result in a blue screen on Windows and an oops on Linux, so same thing again.
If the driver "freezes the PC solid", this means that the driver fiddled with the hardware in a way that caused it to crash and disrupt some bus, so the software architecture (user mode, kernel mode) is irrelevant again - the result will be the same.

[liam]

I think we're mixing "GPU hang" with "driver crash". Linux drivers do reset the GPU when it stops executing commands, as Windows does (you get a line in the kernel log instead of a pop-up menu).
If the memory management part of the driver (which has to be kernel mode) crashes, this will result in a blue screen on Windows and an oops on Linux, so same thing again.
If the driver "freezes the PC solid", this means that the driver fiddled with the hardware in a way that caused it to crash and disrupt some bus, so the software architecture (user mode, kernel mode) is irrelevant again - the result will be the same.

Why does memory management have to be in the kernel? My understanding of microkernels is that memory management is done in a server.
If you mean ntoskrnl, or linux, then I understand your meaning.

[smitty3268]

Windows 7 does this for its video drivers (and others). There are plenty of advantages. One of the primary reasons that Windows 7 barely ever crashes is this very thing, in fact. Microsoft found that over 95% of BSOD's in WinXP and earlier were video driver related. On a similar note, I've had Linux kernel-oops on me quite a few times in the last year, all of which are DRI/DRM/KMS related. Also, the newer WDDM allows video drivers to be installed and updated with reboot, allows video driver crashes to be gracefully handled (your screen goes black and then resets, and most apps don't notice or care; even most well-written games will survive it just fine). Meanwhile the Linux in-kernel model means you have to patch kernels and rebuild half your low-level OS just to get a simple driver fix in, which is nothing short of retarded, and incredibly user-hostile.

The hardware interface is easy to deal with, and Linux already has a means for doing it with various other user-space drivers. There is a small tiny bit of kernel driver (which can even be mostly hardware-agnostic and data-driven) that just sets up the port access and I/O ranges for the userspace driver (which need not run as root, but also should not run as any old user, but rather as an unprivileged system user).

There is a small bit of a performance overhead for this, but obviously this is not a problem: nobody in their right mind accuses Windows of being slow at graphics. In the end, I'd much rather have stability and flexibility and user-friendliness than the 2% extra performance that might be had with in-kernel drivers.

The Win7 graphics architecture split between kernel and userspace is very similar to the one now in linux. Their graphics drivers install kernel driver components, just like they do in linux.

The linux drivers do need to improve a lot to catch up, but it's not really a problem with the overall architecture anymore. Just manpower, and getting rid of X.

I'll agree that the current model of building DRM right into the kernel makes it difficult to do any updates. That could be solved easily by moving the drivers out of the kernel tree, but would increase manpower requirements for the driver teams so i'm not sure it will ever happen.