Filesystems

The QNX Neutrino RTOS provides a rich variety of filesystems. Like most service-providing processes in the OS, these filesystems execute outside the kernel; applications use them by communicating via messages generated by the shared-library implementation of the POSIX API.

These filesystems are resource managers as described in this book. Each filesystem adopts a portion of the pathname space (called a mountpoint) and provides filesystem services through the standard POSIX API (open(), close(), read(), write(), lseek(), etc.). Filesystem resource managers take over a mountpoint and manage the directory structure below it. They also check the individual pathname components for permissions and for access authorizations.

This implementation means that:

• Filesystems may be started and stopped dynamically.
• Multiple filesystems may run concurrently.
• Applications are presented with a single unified pathname space and interface, regardless of the configuration and number of underlying filesystems.
• If you use Qnet, a filesystem running on one node can be made transparently accessible from any other node.

There are some special types of filesystems:

• A pass-through filesystem sits in front of another filesystem and manipulates files that are in the underlying filesystem. An example of this is the Inflator filesystem, which we'll describe later in this chapter.
  Note:

  Running more than one pass-through filesystem or resource manager on overlapping pathname spaces might cause deadlocks.
• A virtual filesystem is one in which the files or directories aren't necessarily tied directly to the underlying media, perhaps being manufactured on-demand. The /proc filesystem is an example; see Controlling processes via the /proc filesystem in the Processes chapter of the QNX Neutrino Programmer's Guide.

• QNX Trusted Disk devices provide integrity protection of the underlying disk data when they are used in a secure boot environment.