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

[erik quanstrom <quanstro@quanstro.net>]

> 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.

/n/sources/plan9/sys/src/9/port/devsd.c:177

> > 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?

there is no race.  the client does a pread/pwrite blithly.  devsd returns
-1, Echange if the medium has changed since the fd was opened.

> > 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.

i assume that you mean a file on a fs not the fs itself.

the qid.vers is *always* device or fs specific.  i don't understand
what specific case you think is broken.  again, it's not expected that
the client look at the qid.vers.  nothing would break if you used
a file on a fs.  (as i do all the time.)  you just wouldn't get Echange errors.

> 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.

as you state it, i agree.  but you're arguing against a qid.vers
usage that dates back to before web browsers.

as i understand it you argue that qid.vers should change for each
write for any server.  many devices just use 0 for qid.vers and never
increment it.  so you can't use qid.vers on a stream or any fs
that just sets qid.vers to 0.  so, in general, one can't use qid.vers
as you propose.

- erik