Sometimes an I/O channel is needed which spans more than two domains. An example may be a file serving application where data arrives from a network device driver, passes to the fileserver process, and then passes to the disk driver.
When such an I/O channel is set up it is possible to share certain areas of Rbuf data memory which are already allocated to that domain for another I/O channel. A domain may wish to have some private Rbufs for each direction of the connection (i.e. ones which are not accessible to domains in the other direction) for passing privileged information. In the fileserver example, the fileserver may have Rbufs which are used for inode information which are not accessible by the network device driver.
The management of the channel may either be at one end or it may be in the middle. In the example of the fileserver, it is likely to be in TMM for communicating with the disk driver, and RMM for communicating with the network driver. The important point is that the data need not be copied in a longer chain provided trust holds.
Figure 8 shows the I/O channels for a fileserver. For simplicity, this only shows the control paths for writes. The iorecs used in the channel between the fileserver and the disk driver will contain references to both the network buffer data area and the private inode data area. Only the network data buffer area is used for receiving packets. The fileserver (operating in RMM) will endeavour to arrange the iorecs so that the disk blocks arriving (probably fragmented across multiple packets) will end up contiguous in the single address space and hence in a suitable manner for writing to disk.
Figure 8: A longer Rbuf channel: Control path for
Fileserver Writes