Passing a file reference should be a first-class VFS operation

[Jakub Jermář]

If one task wants to pass a reference to an open file to another task, the donor task needs to first convert the file descriptor to a VFS triplet by calling fd_node() and send the triplet over IPC to the acceptor task. The acceptor task then gets a new file descriptor for the node corresponding to the VFS triplet by calling open_node(). The node is guaranteed to exist as long as the donor holds the open file descriptor.

This scheme has served its purpose, but is quite ugly, non-atomic and looks like an afterthought in the design of the file system layer and needs to be considered by all of the standard library, VFS, libfs and the endpoint file system servers.

If the donor could somehow reliably identify the acceptor to VFS (which I leave as an open question for now), it would be more elegant to implement a VFS operation for passing open files directly by simply letting VFS lock the donor and acceptor tables of open files and "duplicate" the donor file handle in the acceptor table of open files, including the necessary bookkeeping work.

[Jiri Svoboda]

Note that if the IPC/async framework had support for ports (and their passing from one task to another), this problem would be trivial. An open file would simply be a port and as such it could be trivially passed from one task to another. And you could trivially do the same for any kind of resource (network connection, character device) without it needing to masquerade itself as a file. Need I go on?

[Jakub Jermář]

In mainline,1159, I merged a solution to this problem that introduces a generic IPC mechanism which allows two clients of the same server to negotiate a change of state externally kept in the server. This generic mechanism can be optionally accompanied by a server protocol-specific mechanism to synchronize the acceptor client with the server, such as in situations when the client wants to learn about e.g. what is the new file handle.