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
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.
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 OS that allow you to access services through standard POSIX calls.
Advanced topics
Now that we've covered the basics of resource managers, it's time to look at some more complicated aspects.
Returning directory entries
In the example for the read I/O function handler above, we saw how to return data. As mentioned in the description of the read I/O function handler (in the Alphabetical listing of Connect and I/O functions), this handler may return directory entries as well. Since this isn't something that everyone will want to do, I discuss it here.
Example
In this example, we're going to create a resource manager called /dev/atoz that will be a directory resource manager. It's going to manifest the files /dev/atoz/a through to dev/atoz/z, with a cat of any of the files returning the uppercase letter corresponding to the filename.
dirent_fill()
Finally, the helper routine dirent_fill() is used to stuff the values passed to it (namely, the inode, offset, and fname fields) into the directory entry also passed. As an added bonus, it returns a pointer to where the next directory entry should begin, taking into account alignment.

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.
    - Processes and Threads
      This chapter explains the concepts behind processes and threads, and the challenges of synchronization and scheduling. A thread is a flow of execution, and a process is a collection of threads. In the QNX OS, the schedulable entity is a thread, not a process.
    - Message Passing
      In this chapter, we'll look at the most distinctive feature of QNX OS, message passing. Message passing lies at the heart of the operating system's microkernel architecture, giving the OS its modularity.
    - Interrupts
      In this chapter, we'll take a look at interrupts, how we deal with them under QNX OS, 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 OS 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.
      - 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 OS 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.
        Extending the OCB
        Locking in the resource manager
        The resource manager framework provides facilities for safe thread synchronization in your resource manager. Before you write a multi-threaded resource manager, make sure you are familiar with the default behavior of the shared data structures that thread synchronization uses and the requirements for safely overriding them.
        Extending the attributes structure
        You may wish to extend the attributes structure in cases where you need to store additional information about the resource. Since the attributes structure is associated on a per-resource basis, any extra information you store there will be accessible to all OCBs that reference that resource (since the OCB contains a pointer to the attributes structure). Often things like serial baud rate are stored in extended attributes structures.
        Blocking within the resource manager
        So far we've avoided talking about blocking within the resource manager. We assume that you will supply an outcall function (e.g., a read I/O function handler), and that the data will be available immediately. What if you need to block, waiting for the data? For example, performing a read() on the serial port might need to block until a character arrives. Obviously, we can't predict how long this will take.
        Returning directory entries
        In the example for the read I/O function handler above, we saw how to return data. As mentioned in the description of the read I/O function handler (in the Alphabetical listing of Connect and I/O functions), this handler may return directory entries as well. Since this isn't something that everyone will want to do, I discuss it here.
        Generally speaking...
        Generally speaking, returning directory entries is just like returning raw data, with the exceptions listed here.
        The struct dirent structure and friends
        Let's take a look at the struct dirent structure, since that's the data structure returned by the read I/O function handler in case of a directory read. We'll also take a quick look at the client calls that deal with directory entries, since there are some interesting relations to the struct dirent structure.
        Example
        In this example, we're going to create a resource manager called /dev/atoz that will be a directory resource manager. It's going to manifest the files /dev/atoz/a through to dev/atoz/z, with a cat of any of the files returning the uppercase letter corresponding to the filename.
        main() and declarations
        The first section of code presented is the main() function and some of the declarations. There's a convenience macro, ALIGN(), that's used for alignment by the dirent_fill() and dirent_size() functions.
        my_open()
        While my_open() is very short, it has a number of crucial points.
        my_read()
        In the my_read() function, to decide what kind of processing we needed to do, we looked at the attribute structure's mode member. If the S_ISDIR() macro says that it's a directory, we call my_read_dir(); if the S_ISREG() macro says that it's a file, we call my_read_file(). (For details about these macros, see the entry for stat() in the QNX OS C Library Reference.) Note that if we can't tell what it is, we return EBADF; this indicates to the client that something bad happened.
        my_read_dir()
        In my_read_dir() is where the fun begins. From a high-level perspective, we allocate a buffer that's going to hold the result of this operation (called reply_msg). We then use dp to walk along the output buffer, stuffing struct dirent entries as we go along. The helper routine dirent_size() is used to determine if we have sufficient room in the output buffer to stuff the next entry; the helper routine dirent_fill() is used to perform the stuffing.
        my_read_file()
        In my_read_file(), we see much the same code as we saw in the simple read example above. The only strange thing we're doing is we know there's only one byte of data being returned, so if nbytes is nonzero, then it must be one (and nothing else). So, we can construct the data to be returned to the client by stuffing the character variable string directly.
        dirent_size()
        The helper routine dirent_size() simply calculates the number of bytes required for the struct dirent, given the alignment constraints.
        dirent_fill()
        Finally, the helper routine dirent_fill() is used to stuff the values passed to it (namely, the inode, offset, and fname fields) into the directory entry also passed. As an added bonus, it returns a pointer to where the next directory entry should begin, taking into account alignment.
      - 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 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
- 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.

dirent_fill()

QNX SDP8.0Getting Started with the QNX OSDeveloperUser

Finally, the helper routine dirent_fill() is used to stuff the values passed to it (namely, the inode, offset, and fname fields) into the directory entry also passed. As an added bonus, it returns a pointer to where the next directory entry should begin, taking into account alignment.

struct dirent *
dirent_fill (struct dirent *dp, int inode, int offset, char *fname)
{
    dp -> d_ino = inode;
    dp -> d_offset = offset;
    strcpy (dp -> d_name, fname);
    dp -> d_namelen = strlen (dp -> d_name);
    dp -> d_reclen = ALIGN (sizeof (struct dirent) - 4
                   + dp -> d_namelen + 1);
    return ((struct dirent *) ((char *) dp + 
            dp -> d_reclen));
}

Page updated: March 05, 2025