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:
- 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.
- 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.
- The _IO_READ
logic has to return the data for either the file or directory specified by the pathname.
CAUTION:
Running more than one pass-through filesystem or resource manager
on overlapping pathname spaces might cause deadlocks.