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:
We do notice, however, that fs-qnx6 has registered its association of ND/PID/CHID at the pathname /. Although it's not shown on the diagram, fs-qnx6 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-qnx6 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.