Home
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running the QNX OS 8.0.
Programming
Writing a Resource Manager
Filesystem Resource Managers
Some resource managers need to implement filesystems by responding to access requests for any pathname within a directory structure.
Returning directory entries from _IO_READ
Returning information associated with a directory structure

QNX Momentics IDE User's Guide
This User's Guide describes version 8.0 of the Integrated Development Environment (IDE) that's part of the QNX Tool Suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running the QNX OS 8.0.
- Quickstart Guide
- System Architecture
  The System Architecture guide accompanies the QNX OS and is intended for both application developers and end-users.
- OS Components & Operations
- Graphics
- Programming
  - Getting Started with the QNX OS
    Getting Started with the QNX OS: A Guide for Realtime Programmers is intended to introduce you to the QNX OS and help you develop applications and resource managers for it.
  - Programmer's Guide
    The QNX OS Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX OS.
  - Writing a Resource Manager
    - What Is a Resource Manager?
      In general terms, a resource manager is a process that registers a pathname in the filesystem namespace. Other processes use that pathname to communicate with the resource manager.
    - The Bones of a Resource Manager
      Let's start with the overall structure of a resource manager. First we'll look at what happens under the covers on both the client side and the server side. After that, we'll go into the layers in a resource manager and then look at some examples.
    - Fleshing Out the Skeleton
      It's time now to start adding some flesh to the basic bones of the resource manager. We'll look at the types of messages you might have to handle, how to set the resource manager's attributes, how to add functionality, and some security issues you should consider.
    - POSIX-Layer Data Structures
      The resource manager library defines (in <sys/iofunc.h>) several key structures that are related to the POSIX-layer support routines.
    - Handling Read and Write Messages
      A resource manager must define routines or handlers to process requests by the client to receive data (read) or send data to the underlying device (write). Here, we give detailed examples of such handlers.
    - Resource Managers that Handle Multiple Devices
      Resource managers can easily be adapted to handle multiple devices.
    - Combine Messages
      To conserve bandwidth and to support atomic operations, combine messages are supported. A combine message is constructed by the client's C library and consists of multiple I/O and/or connect messages packaged together into one.
    - Using the Receive Buffer as a Reply Buffer
      When building a response to a client request, you often need a temporary buffer in which to build this response.
    - Handling Other Messages
      Your resource manager will likely need to handle messages for operations other than read and write. Here, we explain and demonstrate how to handle other common message types.
    - Unblocking Clients and Handling Interrupts
      Your resource manager needs to avoid leaving clients blocked indefinitely, and it might need to handle interrupts.
    - Multithreaded Resource Managers
      When you create a multithreaded resource manager, you should design it so that there's always at least one RECEIVE-blocked thread.
    - Filesystem Resource Managers
      Some resource managers need to implement filesystems by responding to access requests for any pathname within a directory structure.
    - Glossary
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX OS system and developers who want to create a QNX OS resource manager free from vulnerabilities.
- Utilities & Libraries
- Migrating to QNX OS 8.0
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX OS in the Amazon cloud environment.
QNX Toolkit for Visual Studio Code
This User's Guide describes the QNX^® Toolkit for Visual Studio Code. The guide introduces you to the QNX Toolkit by explaining the QNX development environment and how to build, run, and debug your QNX^® Operating System (OS) applications and systems.
QNX Hypervisor User's Guide
This User's Guide explains the QNX hypervisor architecture and provides instructions for installing and running a QNX Hypervisor system, changing system components and configuration, and using hypervisor features such as virtual devices (vdevs).
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation, explains how to obtain technical support, and provides some information about licensing.

Returning information associated with a directory structure

QNX SDP8.0Writing a Resource ManagerDeveloper

Instead of returning just the struct dirent in the _IO_READ message, you can also return a struct stat, as a potential optimization. This is basically a usage question. If your device is typically used in such a way that first readdir() is called and then stat() is called, it will be more efficient to return both. If not, it is more efficient to not return the stat information. See the documentation for readdir() in the C Library Reference for more information.

The client can set the xtype member of the message to _IO_XFLAG_DIR_EXTRA_HINT to send a hint to the filesystem to return the extra information, however the filesystem isn't guaranteed to do so. If the resource manager provides the information, it must put it in a struct dirent_extra_stat, which is defined as follows:

struct dirent_extra_stat {
    uint16_t            d_datalen;
    uint16_t            d_type;
    uint32_t            d_reserved;
    struct stat         d_stat;
};

The resource manager must set d_type to the appropriate _DTYPE_LSTAT* or _DTYPE_STAT* value, depending on whether or not it resolves symbolic links and which version of POSIX is being used (see readdir()). For example:

if(msg->i.xtype & _IO_XFLAG_DIR_EXTRA_HINT) { 
    struct dirent_extra_stat    extra;
    extra.d_datalen = sizeof extra.d_stat;
    extra.d_type = _DTYPE_LSTAT;
    extra.d_reserved = 0;
    iofunc_stat(ctp, &attr, &extra.d_stat);
    ...
}

There's a dirent_extra_stat after each directory entry:

Directory structure info — Figure 1Returning the optional struct dirent_extra_stat along with the struct dirent entry can improve efficiency.

Note:

The dirent_extra_stat structure must be aligned on an 8-byte boundary but it follows a variable-length pathname. The d_reclen member of the struct dirent must contain the size of both structures, including any space necessary for the pathname and alignment. There must be no more than seven bytes of alignment filler.

The client has to check for extra data by using the _DEXTRA_*() macros (see the entry for readdir() in the C Library Reference.) If this check fails, the client will need to call lstat() or stat() explicitly. For example, ls -l checks for extra _DTYPE_LSTAT information; if it isn't present, ls calls lstat().

Page updated: March 05, 2025