Next: 3. Mechanisms for Interposition
Up: 2. Background
Previous: 2.3.3 High Development Costs
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.
Next: 3. Mechanisms for Interposition
Up: 2. Background
Previous: 2.3.3 High Development Costs
Erez Zadok
1999-12-07