LWN: Comments on "User-space device drivers"

Event-driven API

Jel — Tue, 19 Jun 2007 08:35:47 +0000

This all sounds pretty horrible. Back in '83 or '84, the Amiga came out,
with a much nicer, event-driven device API. At least from the client
side, it was just a matter of sending events. So, say, for the narrator
device, you would send something like { SET_PITCH, ..., 2000 }, and it
would set the pitch of the speaker's voice. This was asynchronous of
course, so it worked really well with devices like SCSI units/buses.

Presumably the server side was basically just registering a message queue,
and waiting for instructions.

This wasn't a memory-protected kernel, but if we're talking userspace
anyway, then it shouldn't matter. The OS was fully multitasking, and
fairly real-time for the day, as I understand it.

Why not use a model like this?

User-space device drivers

PeterChubb — Tue, 09 Mar 2004 03:13:24 +0000

When a userland driver fails, just kill it and start again. You may lose a few packets (for a network device) or any transactions that are halfway throough (for a disc device), but in most cases, this can be recovered from.

In the case of a kernel mode driver, the same faults often require a reboot...

User-space device drivers

joib — Fri, 30 Jan 2004 16:16:38 +0000

IIRC the Plan 9 operating system allows user-space device drivers. They reason they did that was to bring the development advantages of microkernels described in this article, and then by loading the hopefully debugged driver into the kernel proper the speed benefits of a monolithic kernel are available. I think the point was that the same device driver code could be used for both, though a recompile is almost certainly needed?

User-space device drivers

forthy — Fri, 30 Jan 2004 14:20:17 +0000

The interrupt delivery part is something that has been necessary for years, because X still can't give you any way to syncronize to VBL interrupts (except OpenGL).

On the other hand, I don't feel too happy with user land directly accessing IO ports. This is still dangerous, and buggy X drivers often can hang the machine, too. Memory mapped IO pages should be ok, given that the kernel would allow to map the PCI memory per device, not from /dev/mem. I suggets to keep the IO port part of a device driver inside kernel space.

USB is different

HalfMoon — Thu, 29 Jan 2004 16:04:23 +0000

This Gelato approach would seem to be focussed on a particular style of userspace driver, which works on non-virtualized devices. Specifically, it aims for PCI (or ISA) style devices, where the device driver needs to touch "real hardware".

USB is a good example of a different style driver, one where the device driver can't touch the hardware. In fact you can view USB drivers as the clients in a client/server framework, with the "server" being the device. The bus is really a special purpose network link, used to exchange packets between device and host. (And always initiated by the host, not the device/"server".) So userspace USB drivers work with virtualized devices ... they start with a formalized protocol to talk with the hardware, which doesn't involve register access, IRQs, or memory mapping except indirectly.

There are two approaches right now to userspace USB drivers.

The original "usbfs" (or "usdevfs"), which is in sore need of replacement. It's ioctl-heavy, and multiplexes I/O streams (up to 32 per device) into one file descriptor. And it defines its own async I/O primitives. So while a Java API exists, it's awkward.
"gadgetfs" runs inside USB devices. It's got hardly any ioctls, and uses one file descriptor per I/O stream. Current versions of gadgetfs (not yet in Linux 2.6) use standard AIO calls to support data streaming from userspace.

There are discussions underway to create "usbfs2", which should eventually replace "usbfs". It'll look much more like gadgetfs than "usbfs", with few ioctls and using the standard AIO framework.

So that's something else to keep in mind. This Gelato framework doesn't seem like it'd work well with USB, or with other device models that have already upleveled and virtualized their hardware.

User-space device drivers

jonabbey — Fri, 23 Jan 2004 20:45:48 +0000

Snare's userland audit daemon works in the same way Gelato does.. it loops reading audit events from /proc/audit. This method has the very great virtue of simplicity and it can actually be quite fast and efficient. It'll be neat to see where this goes for user mode drivers, but I wonder what happens if a user mode driver fails? Would the kernel be smart enough to stop preparing the data for the driver? I know when the Snare audit daemon closes /proc/audit, the kernel notices that it has been closed, and amends its behavior to avoid queueing up additional audit events.

User-space device drivers

aleXXX — Fri, 23 Jan 2004 17:44:28 +0000

You can find some information about the kioslave-fuse bridge at:
http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+Gateway

And yes, it works, loading and saving files via konqueror in OOo or gimp
using ioslaves and fuse :-)

You can also contact me directly: neundorf@kde.org

Bye
Alex

User-space device drivers

scripter — Thu, 22 Jan 2004 21:22:26 +0000

http://uservfs.sourceforge.net/

http://sourceforge.net/projects/avf

http://www.freenet.org.nz/python/lufs-python/

User-space device drivers

stuart2048 — Thu, 22 Jan 2004 19:53:54 +0000

What fun! Back in the days of "who's got the fastest IPC" my master's thesis project, the Raven Kernel, was based on a user level approach (for as much as I could get away with...).

I did interrupt dispatching quite differently than Gelato. In Gelato, a user thread "reads" interrupts from an open file descriptor. In Raven, I took a more asynchronous approach: the kernel interrupt handler upcalls into the user driver (essentially interrupting the user code), where it then directly executes the handler code to service the device.

My motivation here was to make the user handler code execute with as low latency as possible. There were some tricky corner cases to implement, but I eventually got it working. ;-)

But after all that, I much prefer the simplicity of Gelato's approach and will stay tuned to their progress!

--Stuart

User-space device drivers

rjw — Thu, 22 Jan 2004 12:37:40 +0000

Google for FUSE and LUFS for the most active user space FS projects. FUSE even has a bridge allowing the use of KDE IO slaves as a mountable filesystem.

User-space device drivers

danshearer — Thu, 22 Jan 2004 05:54:08 +0000

There are several threads hanging out of the "drivers in userspace" tangle.

One of them is filesystems, which are a very logical thing to do in userspace. Peter's work doesn't address that at all. Years ago (back in 2.0) Jeremy Fitzharding (sp?) from Sydney did userfs, which let you do things like mount an ftp site. Some obvious fs candidates such as imapfs involve very long strings and according to (a) people who really know what they are doing and (b) my bumbling experiments, 64k strings are a *really* bad idea in kernel modules.

Another one is virtualisation. Read Jeff Dike on pushing User Mode Linux into kernel space for some clues on where this might be going. Jeff articulates advanced architecture and design better than most, so it is worthwhile looking for his stuff. His idea in this case is to port UML from the current libc interfaces at the backend to kernel interfaces, something like a module. Think of it like IBM's VM with OSs running underneath that, and the kernel of each OS is in true kernel space but within that applications (drivers, in this case) are completely protected.

--
Dan Shearer
dan@shearer.org