From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] 9P2000 From: "rob pike" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20010131021645.EBC6E199F8@mail.cse.psu.edu> Date: Tue, 30 Jan 2001 21:16:27 -0500 Topicbox-Message-UUID: 555a9912-eac9-11e9-9e20-41e7f4b1d025 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