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. Here's a sample command-line session to give you an idea of how this works:

# cd /dev
# ls
atoz    null    ptyp2   socket  ttyp0   ttyp3
enet0   ptyp0   ptyp3   text    ttyp1   zero
mem     ptyp1   shmem   tty     ttyp2
# ls -ld atoz
dr-xr-xr-x  1 root      0                26 Sep 05 07:59 atoz
# cd atoz
# ls
a       e       i       m       q       u       y
b       f       j       n       r       v       z
c       g       k       o       s       w
d       h       l       p       t       x
# ls -l e
-r--r--r--  1 root      0                 1 Sep 05 07:59 e
# cat m
M# cat q
Q#

The example above illustrates that the directory atoz shows up in the /dev directory, and that you can do an ls of the directory itself and cd into it. The /dev/atoz directory has a size of “26,” which is the number that we selected in the code. Once in the atoz directory, doing another ls shows the contents: the files a through z. Doing an ls of a particular file, say e, shows that the file is readable by all (the -r--r--r-- part) and is one byte in size. Finally, doing a few random cat's shows that the files indeed have the stated contents. (Note that since the files contain only one byte, there's no linefeed after the character is printed, which is why the prompt shows up on the same line as the output.)

Now that we've seen the characteristics, let's take a look at the code, which is organized into the following functions:

main() and declarations: Main function; this is where we initialize everything and start the resource manager running.
my_open(): The handler routine for the _IO_CONNECT message.
my_read(): The handler routine for the _IO_READ message.
my_read_dir() and my_read_file(): These two routines perform the actual work of the my_read() function.
dirent_size() and dirent_fill(): Utility functions to deal with struct dirent structure.

Note that while the code is broken up here into several short sections with text, you can find the complete version of atoz.c in the Sample Programs appendix.

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 Neutrino 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. (Note that these routines are not part of the resource manager library; they're discussed and documented below.)
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. Notice how we used the inode member of the attribute structure as the basis of which data to return. This is a common trick used in resource managers that must deal with multiple resources. Another trick would be to extend the attributes structure (as discussed above in “Extending the attributes structure”) and have either the data stored there directly or a pointer to it.
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.

Related concepts

Resource Managers (System Architecture)

Writing a Resource Manager