User-space device drivers [LWN.net]

User-space device drivers

Posted Jan 22, 2004 19:53 UTC (Thu) by stuart2048 (subscriber, #6241)
Parent article: User-space device drivers

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

(Log in to post comments)

User-space device drivers

Posted Jan 23, 2004 20:45 UTC (Fri) by jonabbey (subscriber, #2736) [Link]

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

Posted Mar 9, 2004 3:13 UTC (Tue) by PeterChubb (guest, #20062) [Link]

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...