The following list shows the filesystem supported by QNX:
RAM filesystem: Every QNX system provides a simple RAM-based "filesystem" that allows read/write files to be placed under /dev/shmen.
QNX4 filesystem: This is the native neutrino filesystem.
DOS filesystem: The DOS Filesystem provides transparent access to DOS disks.
CD-ROM filesystem: The CD-ROM filesystem shared library, called fs-cd.so, implements the ISO 9660 standard as well as a number of extensions, including Rock Ridge (RRIP), Joliet (Microsoft), and multisession (Kodak Photo CD, enhanced audio).
Flash filesystem: Some of the flash filesystems supported by QNX are shown: generic flas filesystem (def-generic), SH$7750 Aspen eval board (devf-aspen), PowerPaq eval board (devf-ppag) and so on.
NFS filesystem
CIFS filesystem: This filesystem is known typically as SMB.
Linux Ext2 filesystem: The Ext2 filesystem (fs-ext2.so) provides transparent access to Linux disk partitions.
Virtual filesystem: QNX provides two types of virtual filesystem:
Package filesystem: It is a virtual filesystem that presents a customized view of a set of files and directories to a client.
Inflator: It is a resource manager that sits in front of other filesystems and inflates files that were previously deflated (using the deflate utility).
In conclusion, most of these filesystems are resource managers that adopt a portion of the pathname space (called mountpoint) and provide filesystem services through the standar POSIX API (open(), close(), read(), etc.).
QNX provides a process, called pathname management that manages the pathname space and allows to support the POSIX semantics for device and file access, while making the use of those services optional for small embedded systems.
Some of these devices filesystems or mountpoints are: /dev/hd0, /dev/fd0, /dev/shmem, /dev/mem, /dev/zero, /dev/ser* (serial device), /dev/con* (simple console device), /dev/par* (parallel printer), /dev/pty* (pseudo console device) and so on.
In conclusion, when a process opens a file using the POSIX open() call, the library routine sends the pathname to procnto, where the pathname is compared against the prefix tree to determine which resource managers should be sent this message (This work is realized by pathname management thread).