Pathname-space mapping

Updated: May 06, 2022

You may have noticed that we've talked about files and directories appearing in their parent directories, rather than just saying that the parent directories contain these files. This is because in QNX Neutrino, the pathname space is virtual, dictated not just by the filesystem that resides on media mounted at root, but rather by the paths and pathname aliases registered by the process manager.

For example, let's take a small portion of the pathname space:

In a typical disk-based QNX Neutrino system, the directory / maps to the root of a filesystem on a physical hard drive partition. This filesystem on disk doesn't actually contain a /dev directory, which exists virtually, adopted via the process manager. In turn, the filename ser1 doesn't exist on a disk filesystem either; it has been adopted by the serial port driver.

This capability allows virtual directory unions or unioned filesystems to be created. This happens when multiple resource managers adopt files that lie in a common directory within the pathname space.

Which resource manager looks after which file or directory depends on the length of the matched pathname and order in which the underlying filesystems are mounted, as described in Pathname Management in the Process Manager chapter of the System Architecture guide.

Note: The more filesystems involved in the union, the more complicated things become. In the interests of creating a maintainable system, we suggest that you create directory unions as rarely as possible.

For a more detailed example, see Unioned filesystems in the Resource Managers chapter of Getting Started with QNX Neutrino.