Filesystem Resource Managers

Up until this point, our discussion has focused on resource managers that associate each device name via a discrete call to resmgr_attach(). We've shown how to “take over” individual pathnames. (Our examples have used pathnames under /dev, but there's no reason you couldn't take over any other pathnames, such as /MyDevice.)

A typical resource manager can take over any number of pathnames. A practical limit is on the order of a hundred; however, the real limit is a function of memory size and lookup speed in the process manager.

What if you wanted to take over thousands or even millions of pathnames?

The most straightforward method of doing this is to take over a pathname prefix and manage a directory structure below that prefix (or mountpoint).

Here are some examples of resource managers that may wish to do this:

• An SD card filesystem might take over the pathname prefix /sd1, and then handle any requests for files below that pathname by going out to the SD card device.
• A filesystem for managing compressed files might take over a pathname prefix of /uncompressed, and then uncompress disk files on the fly as read requests arrive. (Such a filesystem is often called a pass-through filesystem, because it will pass some operations through to another underlying filesystem.)
• A network filesystem could present the directory structure of a remote machine called “flipper” under the pathname prefix of /mount/flipper and allow the user to access flipper's files as if they were local to the current machine.

And those are just some obvious ones. The reasons (and possibilities) are almost endless. The common characteristic of these resource managers is that they all implement filesystems.

Filesystem resource managers differ from device resource managers (at least, the ones that we have shown so far) in the following key areas:

1. The _RESMGR_FLAG_DIR bit must be set in the flags argument to resmgr_attach() to inform the process manager that the resource manager will accept matches at or below the defined mountpoint.
2. The _IO_CONNECT logic has to check the individual pathname components against permissions and access authorizations. It must also ensure that the proper attribute is bound when a particular filename is accessed.
3. The _IO_READ logic has to return the data for either the “file” or “directory” specified by the pathname.