FUSE, CUSE, and UIO

Recently I've been spending a little bit of time learning about FUSE, CUSE, and UIO, which are related technologies for user space device driver implementations in Linux.

What ties these various technologies together is that they are Userspace techniques for implementing functionality that previously required kernel-mode programming. As the Userspace I/O HOWTO says:

For many types of devices, creating a Linux kernel driver is overkill. All that is really needed is some way to handle an interrupt and provide access to the memory space of the device. The logic of controlling the device does not necessarily have to be within the kernel, as the device does not need to take advantage of any of other resources that the kernel provides. One such common class of devices that are like this are for industrial I/O cards.

To address this situation, the userspace I/O system (UIO) was designed. For typical industrial I/O cards, only a very small kernel module is needed. The main part of the driver will run in user space. This simplifies development and reduces the risk of serious bugs within a kernel module.

The general UIO framework is now more than 4 years old and is quite well integrated into Linux. There is lots of information available about the general topic of User Space Interfaces in Linux.

FUSE techniques are also quite well-known and accepted, and there is a long list of interesting FUSE implementations, and lots of great documentation about how to build FUSE-based filesystems.

CUSE, which is an extension of FUSE to handle character devices, is younger and still evolving. There is still considerable controversy about how and when to use CUSE effectively.

Apparently there is even a BUSE, for Block device User Space drivers, although this appears to be sketchier still than the CUSE work. And you can certainly find people who still find the whole world of Linux device driver writing controversial, though you'd think that this program would have resolved most, if not all, of those complaints.

Luckily I don't have to write device drivers or filesystems myself, though I find them fascinating to study. I wandered down this path because I was trying to get a more clear understanding of the difference between the f_bsize and f_io_size fields in the statfs structure, and how those fields relate to the f_frsize and f_bsize fields in the statvfs structure. I'm still engaged in that investigation, but at least my side-trip into Linux user-space driver implementations was interesting.