From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <84c03de05d2626f54ae08464b2933408@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] implementing 9p read
Date: Thu,  5 Jul 2007 14:59:34 -0400
From: Sape Mullender <sape@plan9.bell-labs.com>
In-Reply-To: <468D3D99.8010802@wmipf.in-berlin.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 91a03fcc-ead2-11e9-9d60-3106f5b1d025

> Hi,
>=20
> 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 t=
o
> 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?
>=20
> 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 lin=
e
> likely will be shifted or somehow overwritten; this can actually be
> provoked, if one reads e.g. 10 bytes from ctl, enters a character, read=
s
> some more bytes.
>=20
> 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.
>=20
> 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 differen=
t
> buffer content.
>=20
> 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.
>=20
> Which approach would be preferred on Plan 9? Thanks for any advice,
> Michael

Many control files are read using the helper routines readstr and readbuf
(see 9p(2)).
They extract from a string or buffer, the portion needed for the read
command, given seek offset and byte count.  The string buffer is usually
generated anew for each read.  Inconsistencies, therefore, can occur when
the client is a slow reader and the status file changes underfoot.
I don't see how this can be helped other than keeping buffers allocated
on a per open-file basis =E2=80=94 and that would be overkill.

	Sape