Given that communicating long pathnames is required and that a buffer will be needed to retain these pathnames, two principal strategies exist for managing such buffers:
The buffers might be useful for transferring data. However, where file contents are memory-mapped, they become superfluous.
The following considerations apply to the different strategies.
Where clients would be allocating buffers, they would potentially be doing so for the single purpose of communicating a pathname, with the server not then using such buffers. Where this might occur, clients could potentially reuse buffers when opening new files.
(Alternatively, clients could donate their buffers to the pool of pages being used to provide file content, but they would need to completely relinquish them; otherwise, they might be able to interfere with the proper functioning of the filesystem. It might be difficult to enforce this, so it seems that using buffers purely for explicit data sharing is the most appropriate approach.)
There could be concern about servers relinquishing buffers if the client were to reuse them: the server could potentially interfere with the buffers. However, where buffers have been explicitly shared, the assumption would be that the other party would always be able to access them. Any sharing communication buffers would only ever involve two parties.
One fairly convincing argument for having the client allocate the buffers when sharing data with the server is that it follows the natural course of communication. The client will reference the buffer dataspace in its message, thus explicitly indicating the presence of data.
Where servers would be allocating buffers, they would also be doing so to facilitate pathname transfer. However, they would not explicitly share the buffers with clients. Instead, the servers would use the buffers to support operation as dataspaces: clients would write to memory mapped into their address spaces, this memory being provided by the buffers, but the servers would moderate access.
Ultimately, upon opening an actual file, the buffers might then be used as part of the pool of pages providing file content, although it might instead be advantageous to allow the client to use the buffer repeatedly for the purpose of opening files.
With this strategy, the process of accessing a file is as follows:
The following client-side pseudocode can be formulated:
# Allocate dataspace. ds = alloc_dataspace() # Write path to buffer. (This is just a memory-writing operation.) ds.write(path) # Obtain a reference to the file object. f = fs.open(ds)
With this strategy, the process of accessing a file is as follows:
Actually accessing a named file involves the following:
The following client-side pseudocode can be formulated:
# Obtain an context acting as a dataspace. context = fs.open() # Write path to buffer. (This is just a memory-writing operation.) context.buffer.write(path) # Open the actual file. f = context.open(flags)
The following arrangement of classes is involved in the opening of files: