What FUSD Isn't

FUSD looks similar to certain other Linux facilities that are already available. It also skirts near a few of the kernel's hot-button political issues. So, to avoid confusion, we present a list of things that FUSD is not.

• A FUSD driver is not a kernel module. Kernel modules allow--well, modularity of kernel code. They let you insert and remove kernel modules dynamically after the kernel boots. However, once inserted, the kernel modules are actually part of the kernel proper. They run in the kernel's address space, with all the same privileges and restrictions that native kernel code does. A FUSD device driver, in contrast, is more similar to a daemon--a program that runs as a user-space process, with a process ID.

• FUSD is not, and doesn't replace, devfs. When a FUSD driver registers a FUSD device, it automatically creates a device file in /dev. However, FUSD is not a replacement for devfs--quite the contrary, FUSD creates those device files by using devfs. In a normal Linux system, only kernel modules proper--not user-space programs--can register with devfs (see above).

• FUSD is not UDI. UDI, the Uniform Driver Interface, aims to create a binary API for drivers that is uniform across operating systems. It's true that FUSD could conceivably be used for a similar purpose (inasmuch as it defines a system call messaging structure). However, this was not the goal of FUSD as much as an accidental side effect. We do not advocate publishing drivers in binary-only form, even though FUSD does make this possible in some cases.

• FUSD is not an attempt to turn Linux into a microkernel. We aren't trying to port existing drivers into user-space for a variety of reasons (not the least of which is performance). We've used FUSD as a tool to write new drivers that are much easier from user-space than they would be in the kernel; see Section 2 for use cases.