Beautiful Code [221]
struct vop_vector {
struct vop_vector *vop_default;
int (*vop_open)(struct vop_open_args *);
int (*vop_access)(struct vop_access_args *);
and here is how the ISO-9660 filesystem initializes the structure:
struct vop_vector cd9660_vnodeops = {
.vop_default = &default_vnodeops,
.vop_open = cd9660_open,
.vop_access = cd9660_access,
.vop_bmap = cd9660_bmap,
.vop_cachedlookup = cd9660_lookup,
.vop_getattr = cd9660_getattr,
.vop_inactive = cd9660_inactive,
.vop_ioctl = cd9660_ioctl,]
.vop_lookup = vfs_cache_lookup,
.vop_pathconf = cd9660_pathconf,
.vop_read = cd9660_read,
.vop_readdir = cd9660_readdir,
.vop_readlink = cd9660_readlink,
.vop_reclaim = cd9660_reclaim,
.vop_setattr = cd9660_setattr,
.vop_strategy = cd9660_strategy,
};
(The .field = value syntax is a nifty C99 feature that allows fields of a structure to be initialized in an arbitrary order and in a readable way.) Note that although the complete vop_vector structure contains 52 fields, only 16 are defined in the preceding code. As an example, the vop_write field is left undefined (getting a value of NULL) because writing to files is not supported on ISO-9660 CD-ROMs. Having initialized one such structure for every filesystem type (see the bottom of Figure 17-1), it is then easy to tie this structure to the administrative data associated with each file handle. Then, in the FreeBSD kernel, the filesystem-independent part of the read system call implementation appears simply as (see Figure 17-1):
struct vop_vector *vop;
rc = vop->vop_read(a);
Figure 17-1. Layers of indirection in the FreeBSD implementation of the read system call
So, when reading from a CD containing an ISO-9660 filesystem, the previous call through a pointer would actually result in a call to the function cd9660_read; in effect:
rc = cd9660_read(a);
Another Level of Indirection > From Function Arguments to Argument Pointers
17.2. From Function Arguments to Argument Pointers
Most Unix-related operating systems, such as FreeBSD, Linux, and Solaris, use function pointers to isolate the implementation of a filesystem from the code that accesses its contents. Interestingly, FreeBSD also employs indirection to abstract the read function's arguments.
When I first encountered the call vop->vop_read(a), shown in the previous section, I asked myself what that a argument was and what happened to the original four arguments of the hypothetical implementation of the VOP_READ function we saw earlier. After some digging, I found that the kernel uses another level of indirection to layer filesystems on top of each other to an arbitrary depth. This layering allows a filesystem to offer some services (such as translucent views, compression, and encryption) based on the services of another underlying filesystem. Two mechanisms work cleverly together to support this feature: one allows a single bypass function to modify the arguments of any vop_vector function, while another allows all undefined vop_vector functions to be redirected to the underlying filesystem layer.
You can see both mechanisms in action in Figure 17-2. The figure illustrates three file-systems layered on top of one another. On top lies the umapfs filesystem, which the system administrator mounted in order to map user credentials. This is valuable if the system where this particular disk was created used different user IDs. For instance, the administrator might want user ID 1013 on the underlying filesystem to appear as user ID 5325.
Figure 17-2. Example of filesystem layering
Beneath the top filesystem lies the Berkeley Fast Filesystem (ffs), the time- and space-efficient filesystem used by default in typical FreeBSD installations. The ffs in turn, for most of its operations,