VFS and vnode operations vector tables are allocated and built by the PFS, and their addresses are returned in the PFSI. These tables may not be altered after the PFS posts the initialization-complete ECB.

Vnode operations, such as vn_open and vn_readdir, deal with file system objects. VFS operations, such as vfs_mount and vfs_statfs, deal with whole file systems or with the PFS itself.

The routine that supports each particular operation is loaded into storage by the PFS_Init routine, and the entry-point address is placed into the corresponding vector table entry. If the PFS supports the dynamic service activation capability, it must instead supply indirect addresses (that point to the actual entry-point addresses for each operation routine) in the vector table entries and set the pfsi_modind flag in the PFSI. When the LFS processes a VFS or vnode operation request, it will recognize the flag and use the address supplied in the vector table as an indirect address to locate the target operation routine.

If the PFS does not support a particular operation, the corresponding operation's vector must contain 0. The number of operations that are placed in the table by the PFS, as determined by the returned table's length, may be less than or equal to the number of operations that are supported by the LFS. If this value is less, the LFS treats all remaining operations as not supported, just as though the PFS had supplied 0 for those operation vectors. If the table contains more entries than the LFS expects, it is considered a serious product-level mismatch between the LFS and PFS, and the PFS is terminated.

For more information, see the description of vnoptab and vfsotab structures in Interface structures for C language servers and clients.