From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <84d7b8163cb339151fe23e621e8a29f2@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: device-specific qid.version behaviour (was Re: [9fans] QTCTL?)
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon,  5 Nov 2007 12:54:35 -0500
In-Reply-To: <df49a7370711050906y7677c493r11202d6b2a1949f5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: e96fcbc8-ead2-11e9-9d60-3106f5b1d025

>> /n/sources/plan9/sys/src/9/port/devsd.c:177
> 
> ???
> i'm probably being stupid here, but all i see there is devsd dealing
> with its own data structures, with no external qids involved at all.
> an SDunit doesn't correspond with any file that devsd uses, as far as i can see.
> 
>> 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.
> 
> that's absolutely fine. if that's all that's going on, why bother reflecting
> the medium change in qid.vers of the data file? just leave it at 0 and be done
> with it.

the qid.vers does get exported.  i don't think there's a copy of the version stashed
in the kernel that is not visable from the outside.

	; cd /dev/sdD0	# cdrom
	; ls -q
	(0000000004400004 0 00) ctl
	(0000000004400005 0 00) raw
(inserts a cd)
	; ls -q
	(0000000004400004 1 00) ctl
	(0000000004400006 1 00) data
	(0000000004400005 1 00) raw
(reinserts the same cd)
	; ls -q
	(0000000004400004 2 00) ctl
	(0000000004400006 2 00) data
	(0000000004400005 2 00) raw

> that's precisely why i was arguing for a documented exception
> to the version rule: if the version is 0, treat the file as "always changed".
> it's also why i was arguing against implementations like cdfs
> that export a "partial" qid.vers that's neither one thing nor another,
> useful only to clients that know exactly what kind of file it is
> (in which case the information could be provided some other way).
> 
> some lies are worse than others!
> for instance, i've seen a server that put the
> number of (variably sized) records in a file in its size field,
> rather than the number of bytes. i'd definitely say that was
> worse than giving zero, though strictly speaking they're
> both lies...

there's another way to look at this situation.  the fileservers do not
lie.  they are always accurate.  the client's assumptions are faulty.
;-)

this issue deserves some more thought.  stat(5) says length is in bytes.
is stat(5) wrong?  

if we allow too much freedom in 9p, then we will not be able to
write general tools.  if we don't allow enough, we will not be able to
write tools easily and succinctly.

i think this particular case is not too much of a problem because qid.vers
is not used by very many tools, and most of them assume a fileserver
like kenfs or fossil.  (if you can point to a program that devsd breaks,
i'd be interested.)

- erik