Updated: May 06, 2022

Pseudo block driver

Note: To start this driver, you must be logged in as root or have the right abilities.


devb-loopback [loopback loopback_option[,option]]
              [blk option[,option]...] 
              [fs_type options] &

Runs on:

QNX Neutrino


loopback options
The loopback options include global and order-dependent options:
  • Global options apply to all fd= instances. You can specify them anywhere in the loopback options.
  • Order-dependent options apply to all subsequent fd= files.
    Note: You can specify multiple occurrences of the order-dependent options with different values. For example, for read-only access for the first device, and read-write access for the second device, specify the following:


The global options include the following:

The number of asynchronous I/O threads (which are responsible for executing an internal block device read/write as a normal read/write over the external file descriptor). This multithreading is useful if you've specified multiple fd= devices.

The default is 1. You can specify a value of 0 to force all I/O to be performed synchronously in the context of the filesystem caller; it can be higher to prevent this I/O from becoming a bottleneck to the filesystem layers above (appropriate only when multiple fd= paths have been specified). The pool of threads services requests to all fd= files in the order of client priority.

The name by which the loopback pseudo block devices are registered. The default is lo; thus each fd= entry named on the command line appears as /dev/lo0, /dev/lo1, and so on, in order.

Change to the specified user ID after setup. Default is 0.

The order-dependent options include the following:


Each pathname results in the creation of a corresponding block-special device (see the global prefix= option), the content of which is mirrored over the file descriptor using standard read/write calls. You can then mount traditional block filesystems (such as and on top of these pseudo devices and use them transparently.


rw, ro
sync, async
Set the synchronous write mode to use when opening the underlying file descriptor (corresponds to O_SYNC). The effect of this depends on the resource manager responsible for each file (typically it's ignored).

The default is sync.

denyno, denyrd, denywr, denyrw
The SH_DENY* mode to use when opening the underlying file descriptor. A deny mode stops other processes from opening the host file, thus preventing its content from being changed behind the back of the devb-loopback filesystems, which prevents coherence issues. The default is denyrw.
seek, xtype
Configure I/O onto the file descriptor using either an LSEEK+READ combined message or via a READ+XTYPE_OFFSET composite. By default, devb-loopback probes the host filesystem to determine whether it supports the pread() and pwrite() API. The default is xtype.



Specify the number of heads (default 1).
Specify the number of sectors per track (default 1).
blk options


fs_type options
The fs_type options control any filesystem (fs-*.so) module being loaded. Here, fs_type is the filesystem type, such as qnx6 for the Power-Safe filesystem. For the list of supported filesystem options, see the reference for the corresponding shared object. For example, for qnx6, see


The block filesystems in the QNX Neutrino RTOS are implemented as a series of DLL modules and a set of internal APIs. Thus it's possible to mount disk-based filesystems (such as Power-Safe or DOS) only onto released QNX devb-* drivers. The devb-loopback driver implements a mapping between an arbitrary file descriptor and the block API, allowing any resource manager to be used to host a disk filesystem.

Internal function calls, normally targeted at a CAM driver, are translated into standard read() and write() calls onto the host file descriptor, and are used to populate the data content of a pseudo block device, which appears to the system as a disk.



This results in the following arrangement:


The host file needs to be pregrown.

Using devb-loopback in this case adds functionality that a disk filesystem format offers (access times, hard links, etc.) to the devf-* filesystem. In other cases, devb-loopback lets you use the caching (e.g., names and sectors) that supports, but that the resource manager underlying the host file might not.

Driver support


open(), close()
The device must be able to open and close a file descriptor to it. The O_RDONLY and O_RDWR modes should be supported, as should the SH_DENY* share flags and O_SYNC modifier (if those options are used from the devb-loopback command line); the default libc iofunc open handler is suitable.
The device must support a stat method, which is used to determine the size and geometry of the underlying device. The default libc iofunc handler is suitable, provided there's an associated iofunc_mount_t which sets a suitable “blocksize” (the default is 1 byte, which isn't appropriate for use as a block device; it must be one of 512, 1024, 2048, or 4096). See also devctl() (below) and the loopback blksz= option.
read(), write()
The device must support read and write callouts, which are used to transfer “disk blocks” between the device and the filesystem buffer cache. I/O is in units of the advertised block size and within the bounds of the advertised device size. If the device supports the _IO_XTYPE_OFFSET modifier (corresponding to pread() and pwrite()), then that interface is used; otherwise a combined seek plus normal read/write is made.
If _IO_XTYPE_OFFSET isn't supported, then the device must implement an lseek method. The default libc iofunc callout is suitable.



devb-loopback blk cache=256k,vnode=128 \
mount -r -t udf /dev/lo0 /mnt/tts

or via the blk automount= option:

