(Illustration by Gaich Muramatsu)
On Mon, Nov 26, 2018 at 10:24:27AM -0500, Greg Troxel wrote: > Interesting about putting plan9 in the middle; that feels like a wart, > and it's hard to understand how extra protocol translation can make > things that didn't have a way to be done work. It is a bit warty, plan9 doesn't have callbacks, so I'm still not sure how cache invalidation works, which is why optimizing for the no-cache cache is useful. If something is seriously missing it could always be developed as a new extension to the existing protocol ('9P2000.C'?) with the disadvantage that we have to maintain our own clients. Which we would have to do anyway if we didn't begin with the plan9 protocol. > I too am really unclear on the "extension" notion. If this is a set of > extensions to plan9 that are reasonably portable (say, to all posix > systems) and implemented in portable FUSE/plan9 code, then that sounds > fine. But doing anything that only works on Linux sounds like a step > backwards. Extensions are defined in the base protocol, during an initial handshake the client and server negotiate if both support the same extension and fallback on the base protocol if not. I guess a client could run the handshake again with a different proposed extension if it wants to iterate through a few. > Can you point to the plan 9 fuse client you recommend? Haven't tried much of these yet so I can't tell you what the best one is. I've mostly used the v9fs Linux kernel module, and a libixp based client, which is plain 9P2000 without extensions. Here is a random fuse client that seems to support the .u extensions and claims to be as fast or faster than the Linux kernel implementation. https://github.com/svinota/py9p > Can you explain how authentication works? Is there crypto in the p9 > protocol? How are other plan 9 clients on the local machine denied > access? No authentication, I still haven't figured out how the official Tauth/Rauth message flow is supposed to work, I haven't seen a client use those yet. Any plan9 client can claim to be any user which is why I want to treat user identities as claimed by different mountpoints independently and every user will have to prove it's authenticity by providing a valid Coda token. There is no crypto in the protocol and we don't deny access. Access is only local through the unix domain socket that is also used by codacon. JanReceived on 2018-11-26 14:43:02