9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "roger peppe" <rogpeppe@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] QTCTL?
Date: Wed, 31 Oct 2007 22:48:17 +0000	[thread overview]
Message-ID: <df49a7370710311548r8259beey9df573b6f3da6fff@mail.gmail.com> (raw)
In-Reply-To: <f8a91a1b799c091842473a69e4a64a1e@plan9.bell-labs.com>

> remember something similar to what Eric remembers: qid.vers of zero
> means `don't cache'.  It might not be written down; it may have just
> been oral folklore at the labs.

when the 9p2000 man pages were initially posted to this list for discussion,
i made a suggestion to that effect, and i seem to recall rob
saying "not a bad idea, but we haven't done it yet".

it's still not done (or documented, at any rate), but i'm still not
sure it's a bad idea.

> this is not true of devsd devices.  the version is used to deal with
> removable devices.  if you have a cd open and the media is changed,
> i/o to the device will return Echange.

using qid.version to indicate the status of the underlying device
rather than of the file data seems to me like an abuse of the system.
surely a status file would be a better way of indicating media change?

> Why don´t add a QTCTL bit to Qid.type?

if we ignore concurrent usage  (which is, after all, a rare case),
one big issue is idempotency - can i read twice at
the same offset and get the same result; can i write two blocks
at different offsets out of order (a la fcp) and end up with the same file?

there are many possible ways that the read and write operations
can be used in the construction of interesting file systems, but
perhaps the semantics of "regular" files are sufficiently common and
useful that it would be
worth knowing whether a given file adheres to them.

those semantics being something like:
- read or write twice at the same offset will yield the same result
(modulo concurrent writers)
- read or write of several sequential items of data is the same
as one read or write of all the data.
- write, followed by a read at the same offset yields the same data
(modulo concurrent writers again)

so i guess i'd argue for a QTREGULAR (QTDATA?) bit rather than a QTCTL bit.
that way, we could start off by adding that bit to those files that
definitely observed the given semantics, and avoid arguing about
which files were or were not "control" files. (and qid.version==0 could
still be useful as a "treat this file as if it always had a new version number
signifier). (and QTAPPEND is still useful to signify a modification, but
not a complete discarding of the given semantics).

  parent reply	other threads:[~2007-10-31 22:48 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-31 18:40 Francisco J Ballesteros
2007-10-31 18:56 ` Eric Van Hensbergen
2007-10-31 19:13   ` Charles Forsyth
2007-10-31 19:33     ` Eric Van Hensbergen
2007-10-31 19:39       ` erik quanstrom
2007-10-31 20:43     ` geoff
2007-10-31 21:32       ` Charles Forsyth
2007-10-31 22:48       ` roger peppe [this message]
2007-10-31 23:35         ` erik quanstrom
2007-11-01  9:29           ` roger peppe
2007-11-01 11:03             ` Eric Van Hensbergen
2007-11-01 11:19               ` Charles Forsyth
2007-11-01 12:11             ` erik quanstrom
2007-10-31 19:42 ` erik quanstrom
2007-10-31 19:49   ` Eric Van Hensbergen
2007-10-31 20:03     ` erik quanstrom
2007-10-31 20:10       ` Latchesar Ionkov
2007-10-31 20:12       ` Eric Van Hensbergen
2007-10-31 20:17       ` Russ Cox
2007-10-31 20:29         ` Francisco J Ballesteros
2007-10-31 20:48           ` Charles Forsyth
2007-10-31 21:23             ` Francisco J Ballesteros
2007-10-31 21:40               ` Russ Cox
2007-10-31 22:11                 ` Charles Forsyth
2007-10-31 22:26                 ` Francisco J Ballesteros
2007-10-31 22:37                   ` Charles Forsyth
2007-10-31 22:43                     ` Francisco J Ballesteros
2007-10-31 23:32                     ` Eric Van Hensbergen
2007-10-31 23:41                       ` [V9fs-developer] " Charles Forsyth
     [not found]                       ` <606b6f003ae9f0ed3e8c3c5f90ddc720@terzarima.net>
2007-11-01  1:13                         ` Eric Van Hensbergen
2007-10-31 23:54                   ` erik quanstrom
2007-11-01  0:03                     ` Charles Forsyth
2007-11-01  1:25                     ` Eric Van Hensbergen
2007-11-01  1:44                       ` erik quanstrom
2007-11-01  2:15                         ` Eric Van Hensbergen
2007-11-01  7:34                       ` Skip Tavakkolian
2007-11-01  6:21                 ` Bakul Shah
2007-11-01 14:28                   ` Russ Cox
2007-11-01 14:38                     ` erik quanstrom
2007-11-01 14:41                     ` Charles Forsyth
2007-11-01 15:26                     ` Sape Mullender
2007-11-01 15:51                       ` Latchesar Ionkov
2007-11-01 16:04                         ` ron minnich
2007-11-01 16:16                           ` Latchesar Ionkov
2007-11-01 16:21                           ` Sape Mullender
2007-11-01 16:58                             ` Francisco J Ballesteros
2007-11-01 17:11                               ` Charles Forsyth
2007-11-01 17:11                                 ` Francisco J Ballesteros
2007-11-01 17:13                               ` Sape Mullender
2007-11-01 17:38                               ` ron minnich
2007-11-01 17:56                                 ` Francisco J Ballesteros
2007-11-01 18:01                                   ` Francisco J Ballesteros
2007-11-01 18:52                                   ` Eric Van Hensbergen
2007-11-01 19:29                                     ` Francisco J Ballesteros
2007-11-01 23:24                                   ` ron minnich
2007-11-01 17:03                           ` Russ Cox
2007-11-01 17:12                             ` Sape Mullender
2007-11-01 17:35                               ` erik quanstrom
2007-11-01 18:36                                 ` erik quanstrom
2007-11-01 17:13                             ` Charles Forsyth
2007-11-01 17:16                               ` Charles Forsyth
2007-11-01 17:20                                 ` Charles Forsyth
2007-11-01 17:52                             ` Eric Van Hensbergen
2007-11-01 18:00                             ` Latchesar Ionkov
2007-11-01 18:03                               ` Francisco J Ballesteros
2007-11-01 18:08                                 ` Latchesar Ionkov
2007-11-01 18:16                                   ` erik quanstrom
2007-11-01 18:19                                   ` Francisco J Ballesteros
2007-11-01 18:35                                     ` Sape Mullender
2007-11-01 19:09                                       ` Charles Forsyth
2007-11-01 19:07                                         ` erik quanstrom
2007-11-01 17:14                           ` Bakul Shah
2007-11-01 16:17                         ` Sape Mullender
2007-11-01 16:27                           ` Sape Mullender
2007-11-01 16:58                         ` Sape Mullender
2007-11-01 16:59                     ` Bakul Shah
2007-11-01  4:21 Brian L. Stuart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=df49a7370710311548r8259beey9df573b6f3da6fff@mail.gmail.com \
    --to=rogpeppe@gmail.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).