> That is it doesn't compare only the qid.path, so in my syntetic file server I can differentiate between files by using a unique-to-me qid.type and then using qid.path to hold the index of my files in a table? qid.type is defined to be the top 8 bits of the mode so unless you meant QTDIR vs QTFILE, the value can't ...

... question: Internally in the kernel it matches full QIDs dosn't it? That is it doesn't compare only the qid.path, so in my syntetic file server I can differentiate between files by using a unique-to-me qid.type and then using qid.path to hold the index of my files in a table? Seccondly, if I am going to use other bits from qid.type is there any reccomded practice as to ...

...> a) to get the old information b) for dosfs to get wacked over the head so it rereads everything. if you choose b), you need devsd to act like it does. i don't understand why qid.vers is involved. it's the read and writes that mustn't be misleading, so they return a suitable diagnostic (the one that's used by devsd.c is reasonably clear-cut, but devfloppy.c's could be better). ...

>> the qid.vers does get exported. indeed it does. but if clients aren't expected to make use of it, why *is* it exported? i guess i'm arguing that the notions of device medium version (a.k.a. nchanges) and file version are two separate things, and it doesn't really make sense to present the former as the latter. why supress it? it might be useful to some applications to ...

On 11/5/07, erik quanstrom <quanstro@quanstro.net> wrote: the qid.vers does get exported. indeed it does. but if clients aren't expected to make use of it, why *is* it exported? i guess i'm arguing that the notions of device medium version (a.k.a. nchanges) and file version are two separate things, and it doesn't really make sense to present the former as the latter. there's another...

>>> maybe 9p2010 Tread/Twrite could include the qid, which may be supplied by the client (or left out). if qid is supplied then the fs has the option to enforce it; otherwise it works as it does now. simpler yet, a flag to open that would tell the fs it should strictly enforce the change notice by returning an error for a subsequent read if the file was changed after the open.

... Tread/Twrite could include the qid, which may be supplied by ...it uses corresponds to the qid it was given. if in...ramfs 137391:->Rattach tag 9 qid (0000000000000000 0 d) cpu%% cd...ramfs 137391:->Rcreate tag 9 qid (0000000000000001 0 ) iounit 8192 ramfs...ramfs 137391:->Ropen tag 9 qid (0000000000000001 0 ) iounit 8192 ramfs...ramfs 137391:->Ropen tag 46 qid (0000000000000001 1 ) iounit 8192 ramfs...

On 11/5/07, Skip Tavakkolian <9nut@9netics.com> wrote: maybe 9p2010 Tread/Twrite could include the qid, which may be supplied by the client (or left out). if qid is supplied then the fs has the option to enforce it; otherwise it works as it does now. Confused as to what you are saying here - could you clarify? -eric

... i understand it you argue that qid.vers should change for each ...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. it's... Tread/Twrite could include the qid, which may be supplied by the client (or left out). if qid is supplied then the fs ...

... its own data structures, with no external qids involved at all. an SDunit doesn't ... why bother reflecting the medium change in qid.vers of the data file? just leave... 0 and be done with it. the qid.vers does get exported. i don't ... implementations like cdfs that export a "partial" qid.vers that's neither one thing nor...not too much of a problem because qid.vers is not used by very many...