Communication via native IPC
Once a resource manager has established its pathname prefix, it will receive messages whenever any client program tries to do an open(), read(), write(), etc. on that pathname.
fd = open ("/dev/ser1", O_RDONLY);
the client's C library will construct an
io_open
message, which it then sends to the
devc-ser* resource manager via IPC.
read (fd, buf, BUFSIZ);
the client's C library constructs an io_read
message, which is then sent to the resource manager.
A key point is that all communications between the client program and the resource manager are done through native IPC messaging. This allows for a number of unique features:
- A well-defined interface to application programs. In a development environment, this allows a very clean division of labor for the implementation of the client side and the resource manager side.
- A simple interface to the resource manager. Since all
interactions with the resource manager go through
native IPC, and there are no special
back door
hooks or arrangements with the OS, the writer of a resource manager can focus on the task at hand, rather than worry about all the special considerations needed in other operating systems.
nativeQNX OS device driver or filesystem can do, a user-written resource manager can do as well.
Consider FTP filesystems, for instance. Here a resource manager would take over a portion of the pathname space (e.g., /ftp) and allow users to cd into FTP sites to get files. For example, cd /ftp/rtfm.mit.edu/pub would connect to the FTP site rtfm.mit.edu and change directory to /pub. After that point, the user could open, edit, or copy files.
Application-specific filesystems would be another example of a user-written resource manager. Given an application that makes extensive use of disk-based files, a custom tailored filesystem can be written that works with that application and delivers superior performance.
The possibilities for custom resource managers are limited only by the application developer's imagination.