Now, what if the client that you're porting used an I/O manager?
How would we convert that to QNX Neutrino?
Answer: we already did.
Once we establish a file-descriptor-based interface, we're using
a resource manager.
Under QNX Neutrino, you'd almost never use a “raw” message interface.
Why not?
- You'd have to worry about the _IO_CONNECT message that
came in with the client's open() call, or you'd have to figure
out how to find the resource manager if you weren't going to use open().
- You'd have to figure out a way to associate a client with a particular context
block inside of the resource manager. This isn't rocket science, but it
does involve some amount of data management.
- You'd have to provide encapsulation of all your messages, instead of using
the standard POSIX file-descriptor-based functions to do that for you.
- Your resource manager won't work with stdin/stdout-based applications.
For the audio driver example, you couldn't just do
mp3_decode spud.mp3 >/dev/audio;
the open() would most likely fail (if not, then the write()
would, and so on).