The resource manager needs to tell the process manager that one or more pathnames are now under its domain of authority—effectively, that this particular resource manager is prepared to handle client requests for those pathnames.
The serial port resource manager might handle (let's say) four serial ports. In this case, it would register four different pathnames with the process manager: /dev/ser1, /dev/ser2, /dev/ser3, and /dev/ser4. The impact of this is that there are now four distinct entries in the process manager's pathname tree, one for each of the serial ports. Four entries isn't too bad. But what if the serial port resource manager handled one of those fancy multiport cards, with 256 ports on it? Registering 256 individual pathnames (i.e., /dev/ser1 through /dev/ser256) would result in 256 different entries in the process manager's pathname tree! The process manager isn't optimized for searching this tree; it assumes that there will be a few entries in the tree, not hundreds.
As a rule, you shouldn't discretely register more than a few dozen pathnames at each level—this is because a linear search is performed. The 256 port registration is certainly beyond that. In that case, what the multiport serial resource manager should do is register a directory-style pathname, for example /dev/multiport. This occupies only one entry in the process manager's pathname tree. When a client opens a serial port, let's say port 57:
fp = fopen ("/dev/multiport/57", "w");
The process manager resolves this to the ND/PID/CHID/handle for the multiport serial resource manager; it's up to that resource manager to decide if the rest of the pathname (in our case, the "57") is valid. In this example, assuming that the variable path contains the rest of the pathname past the mountpoint, this means that the resource manager could do checking in a very simple manner:
devnum = atoi (path);
if ((devnum <= 0) || (devnum >= 256)) {
// bad device number specified
} else {
// good device number specified
}
This search would certainly be faster than anything the process manager could do, because the process manager must, by design, be much more general-purpose than our resource manager.