Handling directories

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

A typical resource manager can take over any number of pathnames. A practical limit, however, is on the order of a hundred—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:

• A CD-ROM filesystem might take over the pathname prefix /cdrom, and then handle any requests for files below that pathname by going out to the CD-ROM 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.
• 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 the most obvious ones. The reasons (and possibilities) are almost endless.

The common characteristic of these resource managers is that they all implement filesystems. A filesystem resource manager differs from the “device” resource managers (that we have shown so far) in the following key areas:

1. The _RESMGR_FLAG_DIR bit in the flags argument to resmgr_attach() informs the library 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.

Let's look at these points in turn.