Limitations and Future Work

In its current form, FUSD is useful and has proven to be quite stable--we use it in production systems. However, it does have some limitations that could benefit from the attention of developers. Contributions to correct any of these deficiencies are welcomed! (Many of these limitations will not make sense without having read the rest of the documentation first.)

• Currently, FUSD only supports implementation of character devices. Block devices and network devices are not supported yet.

• The kernel has 15 different callbacks in its file_operations structure. The current version of FUSD does not proxy some of the more obscure ones out to userspace.

• Currently, all system calls that FUSD understands are proxied from the FUSD kernel module to userspace. Only the userspace library knows which callbacks have actually been registered by the FUSD driver. For example, the kernel may proxy a write() system call to user-space even if the driver has not registered a write() callback with fusd_register().

  fusd_register() should, but currently does not, tell the kernel module which callbacks it wants to receive, per-device. This will be more efficient because it will prevent useless system calls for unsupported operations. In addition, it will lead to more logical and consistent behavior by allowing the kernel to use its default implementations of certain functions such as writev(), instead of being fooled into thinking the driver has an implementation of it in cases where it doesn't.

• It should be possible to write a FUSD library in any language that supports reads and writes on raw file descriptors. In the future, it might be possible to write FUSD device drivers in a variety of languages--Perl, Python, maybe even Java. However, the current implementation has only a C library.

• It's possible for drivers that use FUSD to deadlock--for example, if a driver tries to open itself. In this one case, FUSD returns -EDEADLOCK. However, deadlock protection should be expanded to more general detection of cycles of arbitrary length.

• FUSD should provide a /proc interface that gives debugging and status information, and allows parameter tuning.

• FUSD was written with efficiency in mind, but a number of important optimizations have not yet been implemented. Specifically, we'd like to try to reduce the number of memory copies by using a buffer shared between user and kernel space to pass messages.

• FUSD currently requires devfs, which is used to dynamically create device files under /dev when a FUSD driver registers itself. This is, perhaps, the most convenient and useful paradigm for FUSD. However, some users have asked if it's possible to use FUSD without devfs. This should be possible if FUSD drivers bind to device major numbers instead of device file names.