Filesystem Resource Managers

Updated: October 26, 2022

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:

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.
Running more than one pass-through filesystem or resource manager on overlapping pathname spaces might cause deadlocks.