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
