The example we used above was that of a serial port resource manager. We also stated an assumption: "Let's assume for now that we need an exact match." The assumption is only half-true—all the pathname matching we'll be talking about in this chapter has to completely match a component of the pathname, but may not have to match the entire pathname. We'll clear this up shortly.
Suppose I had code that does this:
fp = fopen ("/etc/passwd", "r");
Recall that fopen() eventually calls open(), so we have open() asking about the pathname /etc/passwd. But there isn't one in the diagram:
Figure 1. QNX Neutrino's namespace.We do notice, however, that fs-qnx4 has registered its association of ND/PID/CHID at the pathname "/." Although it's not shown on the diagram, fs-qnx4 registered itself as a directory resource manager—it told the process manager that it'll be responsible for "/" and below. This is something that the other, "device" resource managers (e.g., the serial port resource manager) didn't do. By setting the "directory" flag, fs-qnx4 is able to handle the request for "/etc/passwd" because the first part of the request is "/"—a matching component!
What if we tried to do the following?
fd = open ("/dev/ser1/9600.8.1.n", O_WRONLY);
Well, since the serial port resource manager doesn't have the directory flag set, the process manager will look at it and say "Nope, sorry, the pathname /dev/ser1 is not a directory. I'm going to have to fail this request." The request fails right then and there—the process manager doesn't even return a ND/PID/CHID/handle that the open() function should try.