2.4 FiST

The effort to change the vnode interface was driven by the need to simplify the model, and allow new file systems to be written faster. This was partially done by removing old vnode calls such as vn_bread and adding new ones such as vn_map [Rosenthal90]. Changing the vnode interface was akin to changing the ``language'' with which a file system implementor ``spoke'' with the kernel. Several past works -- such as Skinner and Wong's ``Interposer Toolkit'' -- began to address the issue of describing file systems using a higher-level language. The most successful of all is the simple (albeit limited) language used by Amd  [Pendry91,Stewart93] to describe map entries, their types, semantics, etc. Recent work on file system simulators [Bosch96] also moves in this direction, but unfortunately requires a radically different (object oriented) file system interface.

It was natural then to try to find a better language that can describe file systems at a high level, for the following reasons:

• There is a lot of repetition in file system code. Much of the code for file systems in the same operating systems share the same structure, calling conventions, error handling, and more. A translator could reuse code, or generate similar code from templates.

• There are many tedious details that must be maintained, which file system implementors may forget or neglect. For example there are many calls in the vnode interface that are rarely used, yet need to be implemented. A language translator is perfect for offering default actions for any vnode operation that need not be implemented, taking care of basic error handling, and other mundane tasks.

• Generated code will be bug-free. This can reduce debugging and maintenance time greatly. A bug in a kernel resident module often results in system panics, corrupt file systems, and a lengthy reboot.

• If sufficiently abstract, a single file system description can be used to generate either kernel-resident or user-level code. This lets developers maintain and debug a new file system at user level, then move the code into kernel level only when they feel that it is stable enough. Meanwhile applications and utilities can be designed, developed, and tested using the user-level version of the new file system.

• An interposeable file system module typically cannot be binary or source portable because of the different facilities offered by different operating systems. A higher level description can offer portability.

• Maintaining file systems through a higher level language becomes easier. Changes to features can be localized into a few places in a description, whereas when writing file system code directly, the same changes have to be updated and verified in numerous places.