Overview

The Inferno file protocol, Styx, is used for messages between clients and servers. An Inferno server is a machine that provides one or more hierarchical file systems - file trees - that may be accessed by Inferno processes. A server responds to requests by clients to navigate the hierarchy, and to create, remove, read, and write files. The prototypical server is a separate machine that stores large numbers of user files on permanent media. Another possibility for a server is to synthesize files on demand, perhaps based on information on data structures inside the kernel; the prog kernel device is a part of the Inferno kernel that does this. User programs can also act as servers (see file2chan - create file connected to Limbo channel in Chapter 8).

A connection to a server is a bidirectional communication path from the client to the server. A server's file tree is attached to a process group's name space by bind and mount calls. Processes in the group are then clients of the servers: system calls operating on files are translated into requests and responses transmitted on the connection to the appropriate service.

A client transmits requests (T-messages ) to a server, which subsequently returns replies (R-messages ) to the client. The combined acts of transmitting (receiving) a request of a particular type, and receiving (transmitting) its reply is called a transaction of that type.

The Styx protocol contains messages that perform:

Navigation over the file hierarchy
Control of file attributes
Access to data in files
Miscellaneous functions

File operations between any two machines are accomplished by sending requests and receiving replies via the Styx protocol. The protocol supports remote access to files and allows a remote machine to use these interfaces as gateways.

Most programs do not see the Styx protocol directly, rather they make calls to library routines that access files. Their requests are translated by the mount driver, mnt, into Styx messages. Client application programs need not explicitly manage details of the Styx protocol as described in this section.

Styx messages need not be manipulated directly by an application designer. Any file operation that invokes Styx results in messages that perform the necessary operations on the remote name space. The exact set of messages differs depending on the call, but in all cases the complexity is concealed from the developer, who simply invokes mount, open, read and similar system commands as necessary.

Operation

A kernel-resident file server, devmnt, functions as a mount driver that is used by the mount system call to connect the name space of a process to the service provided by a server over a communications channel. After the mount has executed successfully, system calls involving files in that portion of the name space are converted by devmnt into the appropriate Styx messages to the server.

The mount system call issues attach messages to the server to identify and validate the user of the connection. Each distinct use of a connection must mount it separately; devmnt multiplexes the access of the various users and their processes to the service.

File oriented system calls are converted by the kernel into Styx messages. The server devmnt translates these messages into transactions, which are then transmitted to the server as Styx messages over the communications channel. Each transaction is implemented by writing the protocol message to the server followed by reading the server channel to get the reply. Errors in the reply message are turned into system call error returns.

A read or write system call on a file served by devmnt may be translated into more than one message since there is a maximum data size (Sys->ATOMICIO, currently 8192 bytes) for a Styx message. The system call will return when the specified number of bytes have been transferred or a short reply is returned.

[Top] [Prev] [Next] [Bottom]

infernosupport@lucent.com