> Poking around Plan 9 and 9P, I was wondering whether it would be a
> neat hack or some sort of abuse to read and write dynamically served
> files at different offsets to get different semantics, instead of
> reading and writing different files (ctl, clone, etc.) to do that.
>
> Given that the system encourages to perceive files as having arbitrary
> semantics (as opposed to having regular sequential file semantics) it
> would make sense (to me) to have reads and writes at arbitrary offsets
> to have arbitrary semantics as well -- that's, after all, what offset
> (kind of) does on a regular file, too, although in a rather trivial
> way.
The semantics of files on Plan 9 are not as ad hoc as you suggest.
In Unix there is essentially one file server, and thus essentially
one file interface. (There are of course little differences;
for example, can you cat a directory?)
In Plan 9 there are many different file servers, but there are
relatively few different file interfaces. The paucity of distinct
interfaces is essential to being able to reuse common tools
across multiple file systems. Of course, each file server does
implement some special behavior (that's why it exists) but
the most effective ones implement those behaviors in a way
that existing tools continue to work.
A network directory is a special kind of tree, but the
many file servers that provide networks agree on a single
interface. Programs that dial(3) work just as well with
the kernel-provided /net/tcp, /net/il, and /net/ether0
as they do with drawterm's networks (bind /mnt/term/net/tcp /net/tcp)
or with programs like sshnet. If every network server used
a different interface, every program that used the network
would have to be changed when a new kind of network
was introduced. (In Unix they do, and it's very frustrating!)
File servers are of course free to introduce whole new
intrfaces, but they usually do it in a way that simple
programs can continue to use their files. For example,
even though some network directory files have special
semantics, the /net/xxx/0/data file behaves no different
from a pipe, so that programs that can talk to a pipe can
talk to the network, assuming some other program sets up
the connection.
As another example, upas/fs presents your mail box as a file tree.
The mail readers--nedmail and Mail--are deeply aware of
the structure of the tree, but mail-ignorant programs can
still access the files. Upas/fs would be much less useful if
file /mail/fs/mbox/1/2/3/body.jpg
tar c /mail/fs/mbox/1/2/3/body.jpg >/usr/rsc/jpg.tar
lp /mail/fs/mbox/1/2/3/body.jpg
page /mail/fs/mbox/1/2/3/body.jpg
did not work. (In p9p on Unix they don't, and it's very frustrating!)
File servers sometimes have good reason to buck convention,
but doing so always comes at a cost. For example, pipes and
network devices cannot provide random access, so they ignore
the file offset in reads and writes; in doing so they become
incompatible with programs that read the data multiple times
(like page in the above examples). Of course, pipes and networks
are so common, on both Plan 9 and Unix, that many programs
avoid the assumption of random access when possible.
Another common violation is to return a file size of 0 in stat
even though reading the file would produce bytes. File servers
do this because it is not always simple to compute the size
of dynamically-generated file contents; in doing so, they become
incompatible with programs that depend on the file size being
accurate. If upas/fs returned a file size of 0 for body.jpg
(it doesn't), then the tar command above would not work
as well, because it needs to write the file size into the tar file
before it copies in the file contents. (Why can't it seek back?
Because it avoids random access on its output for compatibility
with pipes and networks.) Not-actually-zero-length files
are so common that many programs, on Plan 9 at least, avoid
the assumption that stat's length matches the length of read.
If you want to violate a convention, Plan 9 won't stop you,
but in doing so you give up compatibility with programs that
depend on that convention (bind /net/tcp /proc; ps).
Sure, you could replace ctl and clone and other special files with reads
and writes at magic offsets, but in doing so you give up accessing
those files with standard programs like echo and cat. For me,
the main benefit of user-level file servers is exactly that I can
interact with them from a wide variety of programs, including
scripts and interactive shell sessions. I'd need a pretty compelling
reason before I gave that up.
Russ
P. S. I'll ignore the fact that you've also replaced the human-friendly
names with human-unfriendly magic numbers.)
P. P. S. The usb audio use of offsets is not as bad as it first sounds.
The device consumes written data at a constant rate (say, 176,400
bytes per second for CD audio). You can make a noise ten seconds
from now by writing 1.7MB bytes of zeros (silence) followed by your
sound data. Being able to seek ahead 1.7MB instead just avoids the
need to write the zeros. The file offset is still bytes, not nanoseconds.
