Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. The client’s view
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()).
Inside the C library implementation of open(), a message is constructed, and sent to
the process manager (procnto) component. The process manager is responsible for
maintaining information about the pathname space. This information consists of a tree
structure that contains pathnames and node descriptor, process ID, channel ID, and
handle associations:
Resource managers
Pathname space
(stored by the Process Manager)
Resource managers
(0,1,1,1) procnto / fsys-qnx4 (0,4965,1,1)
(0,1,1,1) procnto
proc dev
procnto (0,1,1,1)
(0,1,1,1)
procnto
boot ser1 devc-ser8250 (0,44,1,1)
(0,1,1,1)
procnto
1 ser2 devc-ser8250 (0,44,1,2)
(0,1,1,1)
procnto
4965 con devc-con (0,725,1,1)
...
...
Neutrino’s namespace.
Note that in the diagram above and in the descriptions that follow, I’ve used the
designation fs-qnx4 as the name of the resource manager that implements the QNX 4
filesystem — in reality, it’s a bit more complicated, because the filesystem drivers are
based on a series of DLLs that get bundled together. So, there’s actually no executable
called fs-qnx4; we’re just using it as a placeholder for the filesystem component.
Let’s say that the client calls open():
fd = open ("/dev/ser1", O_WRONLY);
In the client’s C library implementation of open(), a message is constructed and sent to
the process manager. This message states, “I want to open /dev/ser1; who should I
talk to?”
(1) Query
Client
(2) Response
Process
Manager
First stage of name resolution.
April 30, 2009 Chapter 5 • Resource Managers 193