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 QNX Neutrino 7.1.
Programming
Getting Started with QNX Neutrino
Getting Started with QNX Neutrino: A Guide for Realtime Programmers is intended to introduce you to the QNX Neutrino RTOS and help you develop applications and resource managers for it.
Resource Managers
In this chapter, we'll take a look at what you need to understand in order to write a resource manager. Resource managers are another distintive feature of QNX Neutrino that allow you to access services through standard POSIX calls.
The client's view
We've already seen a hint of what the client expects. It expects a file-descriptor-based interface, using standard POSIX functions.
Handling directories
The example we used above was that of a serial port resource manager. We also stated an assumption: Let's assume for now that we need an exact match. The assumption is only half-true—all the pathname matching we'll be talking about in this chapter has to completely match a component of the pathname, but may not have to match the entire pathname. We'll clear this up shortly.

QNX Momentics IDE User's Guide
This User's Guide describes version 7.1 of the Integrated Development Environment (IDE) that's part of the QNX Momentics 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 QNX Neutrino 7.1.
- Quickstart Guide
- OS Components & Operations
- Audio & Graphics API
- Multimedia
- Networking Middleware
- Programming
  - Getting Started with QNX Neutrino
    Getting Started with QNX Neutrino: A Guide for Realtime Programmers is intended to introduce you to the QNX Neutrino RTOS and help you develop applications and resource managers for it.
    - Processes and Threads
    - Message Passing
      In this chapter, we'll look at the most distinctive feature of QNX Neutrino, message passing. Message passing lies at the heart of the operating system's microkernel architecture, giving the OS its modularity.
    - Clocks, Timers, and Getting a Kick Every So Often
      It's time to take a look at everything related to time in the QNX Neutrino RTOS. We'll see how and why you'd use timers and the theory behind them. Then we'll take a look at getting and setting the realtime clock.
    - Interrupts
      In this chapter, we'll take a look at interrupts, how we deal with them under QNX Neutrino, their impact on scheduling and realtime, and some interrupt-management strategies.
    - Resource Managers
      In this chapter, we'll take a look at what you need to understand in order to write a resource manager. Resource managers are another distintive feature of QNX Neutrino that allow you to access services through standard POSIX calls.
      - What is a resource manager?
        A resource manager is simply a program with some well-defined characteristics.
      - The client's view
        We've already seen a hint of what the client expects. It expects a file-descriptor-based interface, using standard POSIX functions.
        Finding the server
        The first thing that a client does is call open() to get a file descriptor. Note that if the client calls the higher-level function fopen() instead, the same discussion applies—fopen() eventually calls open().
        Finding the process manager
        Now that we understand the basic steps used to find a particular resource manager, we need to solve the mystery of, How did we find the process manager to begin with?
        Handling directories
        The example we used above was that of a serial port resource manager. We also stated an assumption: Let's assume for now that we need an exact match. The assumption is only half-true—all the pathname matching we'll be talking about in this chapter has to completely match a component of the pathname, but may not have to match the entire pathname. We'll clear this up shortly.
        Unioned filesystems
        Client summary
        We're done with the client side of things.
      - The resource manager's view
        Let's look at things from the resource manager's perspective.
      - The resource manager library
        Before we get too far into all the issues surrounding resource managers, we have to get acquainted with the QNX Neutrino resource manager library.
      - Writing a resource manager
        Now that we've introduced the basics—how the client looks at the world, how the resource manager looks at the world, and an overview of the two cooperating layers in the library, it's time to focus on the details.
      - Handler routines
        Not all outcalls correspond to client messages—some are synthesized by the kernel, and some by the library.
      - Alphabetical listing of connect and I/O functions
        This section gives an alphabetical listing of the connect and I/O function entry points that you can fill in (the two tables passed to resmgr_attach()). Remember that if you simply call iofunc_func_init(), all these entries will be filled in with the appropriate defaults; you'd want to modify a particular entry only if you wish to handle that particular message. In the Examples section, below, you'll see some examples of the common functions.
      - Examples
        I'm now going to show you a number of cookbook examples you can cut and paste into your code, to use as a basis for your projects. These aren't complete resource managers—you'll need to add the thread pool and dispatch skeleton shown immediately below, and ensure that your versions of the I/O functions are placed into the I/O functions table after you've done the iofunc_func_init(), in order to override the defaults!
      - Advanced topics
        Now that we've covered the basics of resource managers, it's time to look at some more complicated aspects.
      - Summary
        Writing a resource manager is by far the most complicated task that we've discussed in this book.
    - Sample Programs
      This appendix contains the complete versions of some of the sample programs discussed in this book.
    - Glossary
  - Programmer's Guide
    The QNX Neutrino Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX Neutrino RTOS.
  - The QNX Neutrino Cookbook: Recipes for Programmers
  - Writing a Resource Manager
- Sensor Framework
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX Neutrino RTOS system and developers who want to create a QNX Neutrino resource manager free from vulnerabilities.
- Utilities & Libraries
QNX Hypervisor
The QNX Hypervisor allows you to run multiple OSs on a target system so you can separate critical and non-critical functions, support a wide variety of applications, and reduce hardware costs.
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX software in Amazon Web Services (AWS) and Microsoft Azure (Azure).
QNX Advanced Virtualization Frameworks User's Guide
This User's Guide is aimed at all systems integrators and developers who want to design and build embedded systems using the QNX Advanced Virtualization Frameworks.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation and explains how to obtain technical support.

Handling directories

The example we used above was that of a serial port resource manager. We also stated an assumption: Let's assume for now that we need an exact match. The assumption is only half-true—all the pathname matching we'll be talking about in this chapter has to completely match a component of the pathname, but may not have to match the entire pathname. We'll clear this up shortly.

Suppose I have code that does this:

fp = fopen ("/etc/passwd", "r");

Recall that fopen() eventually calls open(), so we have open() asking about the pathname /etc/passwd. But there isn't one in the diagram:

Process Manager maintained tree structure. — Figure 1QNX Neutrino's namespace.

We do notice, however, that fs-qnx6 has registered its association of ND/PID/CHID at the pathname /. Although it's not shown on the diagram, fs-qnx6 registered itself as a directory resource manager—it told the process manager that it'll be responsible for / and below. This is something that the other, device resource managers (e.g., the serial port resource manager) didn't do. By setting the directory flag, fs-qnx6 is able to handle the request for /etc/passwd because the first part of the request is /—a matching component!

What if we tried to do the following?

fd = open ("/dev/ser1/9600.8.1.n", O_WRONLY);

Well, since the serial port resource manager doesn't have the directory flag set, the process manager will look at it and say Nope, sorry, the pathname /dev/ser1 is not a directory. I'm not going to return this resource manager for this request. The process manager will then fall back to a shorter pathname, and it will be handled the same as /etc/passwd, above. But, importantly, the serial port resource manager won't have to deal with it.

Note:

Obviously, as hinted at in my choice of parameters for the open() call above, it may be a clever idea to allow some traditional drivers to be opened with additional parameters past the usual name. However, the rule of thumb here is, If you can get away with it in a design review meeting, go ahead.

Page updated: March 12, 2026