The prototype for mount() is as follows:
int mount( const char *special_device,
const char *mount_directory,
int flags,
const char *mount_type,
const void *mount_data,
int mount_datalen);
The argument that we need to consider here is the flags field.
To support the mounting of non-existent special devices (such as NFS devices) or arbitrary strings (such as the name of shared object or DLL), we need to massage the arguments to this function slightly because the mount utility has two methods (-T and -t) for specifying the mount type.
In the general case where special_device is an actual device, a typical mount command may look like:
% mount -t qnx6 /dev/hd0t177 /mnt/fs
In this case the special_device is /dev/hd0t177, the mount_directory is /mnt/fs, and the mount type is qnx6. In this case, the mount request should be directed only to the process responsible for managing the special_device. That is to say the resource manager that has provided the /dev/hd0t177 path into the pathname space. In this type of scenario, the resource manager is given an OCB for the special_device (/dev/hd0t177), rather than the string /dev/hd0t177. This simplifies the processing in the resource manager since having the OCB, which is an internal data pointer, for the special device implies that the server doesn't have to recursively communicate with itself to get a handle for the device.
A less frequently used, but very useful case, is where the special_device isn't an actual device. For example:
% mount -T io-pkt /lib/dll/devnp-e1000.so
Note that the mountpoint is missing from the command line. In this case, NULL (or /) acts as an implied mount_directory, which causes the process handling the request (i.e., the currently running variant of io-pkt) to take the appropriate action when it receives the mount request. The special_device is /lib/dll/devnp-e1000.so and the type is io-pkt.
In this case, you want to avoid having the special device interpreted as being provided by the same process that will handle the mount request. So while the file /lib/dll/devnp-e1000.so is probably handled by some filesystem process, we're actually interested in mounting a network interface that's managed by the io-pkt process. Ideally, the mount callout will receive only the special device string /lib/dll/devnp-e1000.so, and not the OCB for the device.
The behavioral difference between the -t and -T options for the mount utility can be obtained by ORing in _MFLAG_OCB to the standard mount() flags parameter. If you don't want to use the OCB method of performing the mount request, use -T, which we translate to _MFLAG_OCB.
Mount requests are connection requests, which means they operate on a path in the same way that the open() or unlink() calls do. The requests are sent along the path specified by dir. When a resource manager receives a request to mount something, the information is already provided in the same way that it would be for an open() for creation request, namely in the msg->connect.path variable.
For more information on the name-resolution process, see “Handling private messages and pulses” in this chapter.