Filesystems are implemented as resource managers under QNX Neutrino.
At the highest level, the mount point is represented by the mount structure, iofunc_mount_t. Directories and data elements (files, symlinks, etc.) are represented by the attributes structure, iofunc_attr_t, which is almost always extended with additional information pertaining to the filesystem.
Note that this representation may look almost exactly, or nothing like, the on-disk data structures (if there even are any). For example, the disk structures corresponding to an MS-DOS filesystem have no concept of QNX Neutrino's iofunc_attr_t, even though the filesystem itself has concepts for files and directories. Part of the magic of a filesystem resource manager is that it arranges the attributes structures to mimic the perceived organization of the on-media (if any) data structures.
In our previous example, the filesystem might be represented internally as follows:
Figure 1. Internal resource manager view of a filesystem.The example above shows the data structures leading up to the file /home/jack/spud.txt. The numbers in hexadecimal (e.g., 0x7800333) are sample addresses of the data structures, to emphasize the point that these things live in memory (and not on a disk somewhere).
As you can see, we've used extended versions of the regular resource manager structures. This is because the regular structures have no concepts of things like directories, so we need to add that kind of information. Our attributes structure extensions are of two types, one for directories (to contain the names of the components within that directory) and another for data elements (to contain, in this example, the data itself).
Note that the attributes structure for the data element is shown containing the data directly (this would be the case, for example, with the RAM disk—the data is stored in RAM, so the extended attributes structure would simply contain a pointer to the block or blocks that contain the data). If, on the other hand, the data was stored on media, then instead of storing a pointer to the data, we might store the starting disk block number instead. This is an implementation detail we'll discuss later.