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.