Re: [9fans] 9P2000

["rob pike" <rob@plan9.bell-labs.com>]

Thanks for your thorough reading and commentary.  As you can
imagine, there were endless weeks of debate over many of the
issues in the protocol.

	* restrict allowable contents of file, owner, and group names
	  at the protocol level to be equivalent to the restrictions
	  imposed at the Plan 9 kernel level.

It's unwise to prohibit things in a protocol when you don't know for
certain that they aren't useful.  We have changed the legal character
set for file names in Plan 9 several times, but have not yet had to
make any change to the character set for 9P.  This is evidence that
we're making prohibitions in the right places.

	* eliminate the useless special case of ~0 tags.

Only useless if you don't allow Tsession to reset a connection.

	* eliminate multiple Tsessions from the protocol; require
	  that each connection begin with exactly one Tversion,
	  exactly one Tsession, and disallow any further occurrences
	  of Tsession and Tversion in the conversation.  then the
	  funny "aborts all transactions" semantics of Tsession can
	  also be eliminated.

The requirement for Tsession to reset a connection is there so 9P can
be used on point-to-point wired networks such as the old BIT32 or
other back-to-back bus devices.  If every connection to the server
begins as an IP call, I admit Tsession is less useful, but there are
setups for which Tsession provides the necessary reset capability.  ~0
is a reserved tag so one may always issue a `reset' this way.

	* specify a "minimum maximum" msize that a client can request
	  in such a way that the client can always read() any stat
	  structure that the server might need to return for any
	  possible directory entry.

The issue of going variable-sized in this protocol is by far the most
subtle, difficult, and pervasive issue.  There are still rough edges
around all this area.  The new kernel does only very preliminary stuff
here.  There's no question we need to be careful, but it's all so new
(and hard!  dirread was a bear!)  I want practice to guide our design.
The basics are in the protocol spec. but lots of details remain to be
filled in.

The particular case you raise here is nasty, but only superficially.
You get an error back on the stat or read; that can happen anyway.

The problem with setting a minimum is that it cascades into other size
issues.  How big is the biggest stat?  How does the server know a
priori?  Etc. Etc. Also, if you set a minimum, it means you can't use
that connection to encapsulate.  That feels ugly.

Again, I want to see how this plays out before defining more
explicitly.

	* expand time stamps to 64 bits for posterity.

2038 is coming, but the clock actually overflows in 2106.  This is
one we talked to death.  The earliest drafts had 64-bit clocks but
we backed down for several reasons:
1) Clocks are used everywhere and vlongs are large, slow, and
	painful to work with.
2) Too many other fields have doubled in size; we wanted to
	keep the overall size of the protocol small.  Much of the
	purpose of this revision is performance.   (For instance,
	we kept Qid.version at 32 bits.)
2) All the existing interface software uses 32 bit clocks.
3) 2106 is a long time from now.
4) Mk's clock resolution may be an issue, but mk is enough of
	a crock we'd rather force people to think about how to
	build software than make everything slower to support
	mk.
5) Retrofitting existing timestamps into 64-bit resolution is
	a nasty issue for servers.
6) Finally, no design for how the 64-bit clock should be set
	up looked good in practice.  Nanoseconds? Microseconds?
	Milliseconds?  If we choose (say) microseconds, what does
	it mean to say a file has that time stamp?  The bits may
	be there but they're meaningless in practice. And whatever
	you choose, it's wrong for some future technology if you
	depend on the precision of the clock to make critical
	decisions, as does mk.  Better to face the real issue some
	other way and keep times around mostly for humans,
	as in ls -l output.
In short, leaving clocks alone, as 32 bits of seconds from 1970.0, is
compatible with every other system out there, including our own.

	* forbid attempts in wstat to alter the length of a directory.

This may make sense, but I hardly think it's worth the time to
specify.  And again, that issue about forbidding things too soon...

	* remove discussion of Plan 9 group leader semantics and
	  other weird stuff from the protocol specification.
	  similarly remove the claim that wstat cannot change file
	  ownership from the specification.  instead say that
	  allowable owner, group, and permission changes are
	  determined at the discretion of whatever security policy
	  the server chooses to implement.  (the discussion of Plan 9
	  group semantics would presumably migrate to the man page
	  for the specific file server.)

I have some sympathy with this one.  The protocol is a peculiar
place to write down all this permission stuff.

	* ensure that walks to .. are reliable by explicitly requiring
	  at the protocol level that the hierarchy is always a strict tree.

The hierarchy is not a strict tree in many of our existing servers.

	* disallow walks to "" (the zero length name) in addition to the
	  already-disallowed walks to "."

Existing practice depends on "" meaning ".", particularly within
file names such as "#e".  I'm not sure empty strings go across the wire,
but I'm also not sure they don't.  This one may be worth clarifying.

	* in walk operations that fail, newfid should be implicitly clunked
	  unless it was equal to fid.

The manual says that newfid is unaffected in that case, and that
newfid must not be in use.  I think this is correct and sufficient.

-rob