When creating an MFS, a programmer must consider carefully the environment and purpose of the MFS. Developers should remember that an MFS can (and should) function generically within the OpenInsight system.
In an ideal system, an MFS is compatible with all possible BFSs. At the same time, an MFS should be prepared to handle the full range of calls that might pass to it from higher levels of the system.
To maintain true independence of an MFS, it is important that MFS programmers not assume information that is unique to a BFS. For example, each BFS uses a unique structure for its file handles, lock semaphores, and select pointers. An MFS that is designed to manipulate any of these based on a specific structure will become BFS-bound, and will not be installable on files associated with different BFSs.
As another example, it would be very inflexible to build direct calls to RTP57 (the Linear Hash BFS) into an MFS. Doing so would preclude installing additional an MFS for the file, and would prevent the MFS from being used for other filing systems.
Of course, there is no restriction on the creation of such a BFS-bound MFS. Particular applications will occasionally require precisely this type of MFS for reasons of efficiency or security, or for other reasons. Under these circumstances, an MFS programmer is wise to build checks into the MFS (such as testing the BFS argument) to insure that if the MFS is inadvertently linked to the wrong BFS, it is able to recover and proceed.
