Re: device-specific qid.version behaviour (was Re: [9fans] QTCTL?)

["roger peppe" <rogpeppe@gmail.com>]

On 11/5/07, erik quanstrom <quanstro@quanstro.net> wrote:
> i think something's lost in the translation here.
>
> the client is not responsible for checking the qid.version.  the
> server (e.g. devsd, devaoe or devfloppy) does the qid checking
> itself.

i'm sorry? the server is the one *generating* the qid, surely?
for instance, in the case of cdfs, the version number comes from the
scsi(2) library function, and doesn't have any necessary correspondence with
qid.vers as found in the data file served by cdfs. so strictly speaking,
the server isn't doing any qid checking at all - it's just looking at
its own data structures.

> using a seperate file to detect media change introduces a
> race.  with network-attached media this might be a problem.

there's a race anyway if you're doing the stat in a separate process.
if you're not, then it's the same either way, no?

> the fact is, you can't deal with a physical disk like /dev/sdE0/data
> in the same way you can deal with a regular fileserver.

perhaps not. but by putting device-specific information in qid.vers,
you run the risk that you can't treat a file on a regular fileserver
as if it was a physical disk, and i really like being able to do that.

and i'm afraid i really disagree with the following:

> seriously, the fewer rigid rules we make for 9p,
> the more adaptable it will be.

i feel that real adaptability comes from having a few, well-defined
rules, and freedom within those rules. that way you get
good interoperability, but also flexibility, because the rules
aren't really that restrictive. for me, 9p's unwritten rule seems
to be "if you do it, do it right", whether you're talking
about versions, sizes, read/write offsets, or whatever.

> try doing ls -lt /mail/fs/mbox.

i wish this worked!