From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <468D3D99.8010802@wmipf.in-berlin.de>
Date: Thu,  5 Jul 2007 20:51:05 +0200
From: =?UTF-8?B?TWljaGFlbCBUZWljaGdyw6RiZXI=?= <mt@wmipf.in-berlin.de>
User-Agent: Icedove 1.5.0.8 (X11/20061208)
MIME-Version: 1.0
To: 9fans@cse.psu.edu
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [9fans] implementing 9p read
Topicbox-Message-UUID: 919b0ee4-ead2-11e9-9d60-3106f5b1d025

Hi,

while thinking about whether it would make sense to use 9p for a rather
small embedded device, where Inferno or Plan 9 cannot be run (similar to
styx-on-a-brick), I came to the problem how to implement read access to
dynamic status files, like the `status' named text files on plan 9, or
files like acme's tag or ctl files. An important question seems to be:
When is the textual contents of such a file allowed to change?

For example, a text file like /mnt/acme/1/ctl: If I enter a character
into buffer 1, a certain number within the ctl file will be updated.
What if someone is reading `ctl' (using the same file descriptor)
just before and after the character is inserted - is its contents
allowed to change while the user does subsequent read() calls? This
could give him a corrupted snapshot of ctl, since parts of the text line
likely will be shifted or somehow overwritten; this can actually be
provoked, if one reads e.g. 10 bytes from ctl, enters a character, reads
some more bytes.

Under the condition that a ctl/status file is expected to be read by
`cat' or similar programs only, which read the whole file at once with
a large enough buffer, there will be no problem, as the text will be
consistent.

Is this the way to go? I.e. a 9p Read message arrives, the file server
just `sprint's status data into a buffer, and returns the requested
parts of it. If the user does seek operations, or reads only some bytes
at once, it is his problem if another sprint call results in a different
buffer content.

A different approach could be to allocate a new buffer for each user
opening the status file (i.e. for each fid), and `sprint' status data
only once into each buffer. This way each user always would see a
consistent text file, regardless of whether he performs seek operations
on it or reads only small chunks. Obviously this approach is also more
memory consuming.

Which approach would be preferred on Plan 9? Thanks for any advice,
Michael