Moving Linux Kernel Drivers To User-Space? Nope.

[peppepz]

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.

Memory management is one of the few things that are still done by the kernel even in microkernel designs. How do you allow two untrusted processes to share a common resource without a privileged supervisor between them? Microkernels still have to manage memory and IPC themselves.

[liam]

Memory management is one of the few things that are still done by the kernel even in microkernel designs. How do you allow two untrusted processes to share a common resource without a privileged supervisor between them? Microkernels still have to manage memory and IPC themselves.

That is a good point and the literature agrees with you.
I had thought that you could have a VMM outside the kernel that acted sort of like a memory driver which would only communicate with the kernel.

[libv]

Erm... To all those that are claiming that graphics drivers need to be in kernelspace for performance reasons, and are implying that they are at this point, think again.

What bits of graphics drivers are currently in kernelspace:
* modesetting: the ultra-slow, low frequency part of any graphics driver.
* memory management.
* interrupt handling.
* some command stream/job submission management.

What do you think is missing there? Oh, just about most of the real work, as that is in userspace (even in the only real world that most phoronix forum users accept, namely, just Mesa), which is where all the real work where the most optimization happens as well.

Now. There is something to be said for making graphics drivers and wifi drivers modular, be able to build and load them without rebuilding the whole kernel, and to toss linus over a "stable" version once every kernel release or blue moon.

[Ex-Cyber]

You can have a userspace process in charge of handling map/unmap requests from other userspace processes and generating page tables, but the actual setup/teardown of mappings has to happen in the kernel. IIRC, the way MINIX 3 handles this is that there's something like a "replace a process's old page table with this new page table" syscall/message.

[balouba]

Userspace : you can have proprietary, closed source modules. THAT is the reason. ANd it's such a a sucky one.

Not having a standard interface doesn't stop them tho, theres many, many user space drivers with GPL kernel glue. Personally, I think they're assholes.

[liam]

You can have a userspace process in charge of handling map/unmap requests from other userspace processes and generating page tables, but the actual setup/teardown of mappings has to happen in the kernel. IIRC, the way MINIX 3 handles this is that there's something like a "replace a process's old page table with this new page table" syscall/message.

OK, that does make sense, though it does seem to indicate that memory management doesn't need to happen exclusively in the kernel.

[Ex-Cyber]

The key thing is that there is no inherent privilege involved in merely constructing a data structure, whether it be a memory mapping, a task queue, a shader program, or whatever; the true privilege lies in elevating it into a a more privileged/active/authoritative state. Everything else can be delegated to a less privileged layer. Whether it should be so delegated is largely a question of priorities and preferences, which is why Linus and Andy were able to flame each others' stances without ending either of their respective careers.

[Eduard Munteanu]

Drivers in userspace = slower, harder to manage, can crash your system anyway because they talk directly to the hardware, must be run with high privileges and are therefore a security threat.

Does it sound familiar? Yes, we already have that in Linux: the X server is a driver in userspace, that's why it needed to run as root, and people are doing a lot of work to get away from that design.

Not true, this isn't your regular driver in userspace approach, have a look at that article. It's already been done in virtualization contexts, and there it's better known as PCI passthrough. It lets the host safely hand over an entire PCI device to an OS, provided the machine has an IOMMU. The IOMMU handles address and interrupt remapping and checking, so you can safely let an unprivileged process directly talk to a device without fearing it could DMA all over the memory or do other nasty things.

As far as I understand, the overhead versus the older approaches (involving lots of IPC) is considerably reduced. The only concern I can think of is interrupt delivery, that still seems to involve going through the kernel, which in turn signals the responsible process (so it seems you can't have a fast top handler e.g. quickly download buffers and acknowledge the interrupt). I'm not sure how much of a problem that actually is in practice, but I'd like to hear more in case somebody has a better insight into this.

[qbix]

nice for network drivers

There are different kinds of devices and thus different kinds of drivers. What is right for a timer or a FIFO-based UART might not be right for an Ethernet device. There are also different usages of devices and thus different applications.

For network devices (e.g. Ethernet interfaces), I would much prefer a user space driver where I can seamlessly add (integrate) my layer-2/3 (e.g. VLAN, tunnels, bridges, IPSec etc) and above (mostly UDP and applications using UDP) processing directly on top. The kernel only has to provide UIO support, promoting interrupts to a descriptor that is used by user space to block on when necessary. When (at least one) a packet becomes available, user space is woken up but the device interrupt is not enabled (unmasked) immediately. Only when user space has retrieved and processed all packets and wants to block again, the interrupt is re-armed. This is similar to how NAPI work in the Linux kernel, it increases throughput and avoids live-lock and starvation.

This concept of user space drivers and packet processing is more or less how it works with Intel Data Plane Development Kit (DPDK), Freescale User Space DPAA (USDPAA), NetLogic HyperExec (in Linux user space and not in their NetOS almost-bare metal environment) and in Tilera Zero-Overhead Linux (ZOL). Possibly something similar is available on Cavium OCTEON, at least with Montavista Linux.

The reason is that packet processing is the application of the system and network drivers are not just a kernel service. But with such a design, could also the kernel utilize user space network drivers? Can the kernel utilize user space file systems?

[liam]

The key thing is that there is no inherent privilege involved in merely constructing a data structure, whether it be a memory mapping, a task queue, a shader program, or whatever; the true privilege lies in elevating it into a a more privileged/active/authoritative state. Everything else can be delegated to a less privileged layer. Whether it should be so delegated is largely a question of priorities and preferences, which is why Linus and Andy were able to flame each others' stances without ending either of their respective careers.

I think that is a great description of the minimum kernel functionality.
BTW, apparently QNX performs its memory management in user space. I'm a bit curious how scalable that solution is since it is designed for extremely constrained systems.