10
ramfs -- A Styx server in Limbo

perky$ srv
srv: usage: srv name
srv [-v] [-abc -m mountpoint] [name] [machine!]port
srv [-dv] [-abc -m mountpoint] [name] path/file

ramfs is an in-core file system implemented in Limbo. It should be a blueprint for Stx servers.

ramfs.b itself handles Styx messages as function calls, i.e., there has to be a Server module . Central datastructures are tha adts File to describe a file and Fid to describe an access. Uid is a rudimentary user identification.

srv.b ensures that Styx messages arrive and answers are sent back. The transport can be standard i/o, a TCP port, or demon(). However, apparently demon() exhibits serious problems with memory management in the Inferno 1.0 kernel.

rpc.b produces function calls from Styx messages and packs the results as Styx replies. I prefer this solution to the Plan 9 architecture using global Fcall structures for decoded messages.

The Styx module defines the necessary constants and styx.b implements a number of service functions, in particular, the adts Qid to identify and Stat to describe files and Fcall to manipulate messages.

blk.b depends on the Styx module and can transport and visualize Styx messages.

With the Styx message language sl one can test ramfs in a pipeline; however under Inferno 1.0 a longer pipeline gets stuck.

perky$ sl <in | blk -v | srv ramfs | blk -v >/dev/null

in contains a number of commented tests, run avoids the pipeline. ramfs can be started and mounted locally with commands such as:

perky$ srv -bc -m /tmp 1234

26/Apr/1998