I never much liked .u so I'm happy to see it go away :-) But I wonder what the failure of .u says about the version mechanism. In the 9p stuff I did in 1998 for linux I used the SunRPC way of handling protocol variants: client asked to do an op (e.g. Treadlink) and got back an ENOSUPPORT if server couldn't do that. Client would then shortstop the operation on the client side from that point on, as it knew what the server could and could not do. That worked well for both me and SunRPC (i.e. NFS).
(I had no choice at the time; this was a little bit before Tversion existed). That might work but Plan 9 servers currently silently discard T messages they don't understand, so this way of determining server capabilities can't be used. My impression is that if you see .L, then extra operations are supported and you assume they'll work; is that true? There are other issues with the versioning mechanism however. What if a server supports capabilities of two versions, e.g. .L and .op? Do we reply 9p2000.L+9p2000.op It seems we made the first real test of versioning with .u and things did not go as we hoped ... As for the uid/gid mess, the simplest way out it seemed to me was to send the numbers as strings; done. People can just put the strings for the numbers in /etc/passwd; that's what I did anyway. And, finally, errno and errstr. Plan 9 speaks strings, Unix integers, Windows strings IIRC. The solution for unix clients was reverse mapping of errstr to errno, which has not worked well for me. I'd still prefer the format I used before: sprint(rmsg.error, "%d:%s", errno, errstr); and let the client figure out which of these two things it wants. Obviously useless for Plan 9 servers but very useful for *nix clients/servers, which only want to talk errno. Even if the Plan 9 client sees an errstr in the number:message format, that could be helpful to users. So, sorry to disinter this old discussion, but my $.02 and the pinon coffee just woke me up a little. ron
