A problem that comes up frequently in modern operating systems is contention for a single resource by multiple competing processes. In UNIX, it's the job of a device driver to coordinate access to such resources. By accepting requests from user processes and (for example) queuing and serializing them, it becomes safe for processes that know nothing about each other to make requests in parallel to the same resource. Of course, kernel drivers do this job already, but they typically operate on top of hardware directly. However, kernel drivers can't easily be layered on top of other device drivers.
For example, consider a device such as a modem that is connected to a host via a serial port. Let's say we want to implement a device driver that allows multiple users to dial the telephone (e.g., echo 1-310-555-1212 > /dev/phone-dialer). Such a driver should be layered on top of the serial port driver--that is, it most likely wants to write to /dev/ttyS0, not directly to the UART hardware itself.
While it is possible to write to a logical file from within a kernel device driver, it is both tricky and considered bad practice. In the words of kernel hacker Dick Johnson, ``You should never write a [kernel] module that requires reading or writing to any logical device. The kernel is the thing that translates physical I/O to logical I/O. Attempting to perform logical I/O in the kernel is effectively going backwards.''
With FUSD, it's possible to layer device drivers because the driver is a user-space process, not a kernel module. A FUSD implementation of our hypothetical /dev/phone-dialer can open /dev/ttyS0 just as any other process would.
Typically, such layering is accomplished by system daemons. For example, the lpd daemon manages printers at a high level. Since it is a user-space process, it can access the physical printer devices using kernel device drivers (for example, using printer or network drivers). There a number of advantages to using FUSD instead: