From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 12 Nov 2008 13:31:48 -0600 From: "Eric Van Hensbergen" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <5d375e920811121100o15702c64ufb6e367220606058@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1226365206.17713.390.camel@goose.sun.com> <5d375e920811110830k1c91a401y5e6f39f1737d4240@mail.gmail.com> <140e7ec30811110954u44f8f9aeg788dc34b7d35ac69@mail.gmail.com> <140e7ec30811111811i15f2e2bp3761d477e6c90aed@mail.gmail.com> <13426df10811112058q5f54d697x80152b170524a296@mail.gmail.com> <886E16CF-8F8F-455E-A556-7770EADC77CB@sun.com> <13426df10811120947g8b6c82kd8a65a50e12bae0d@mail.gmail.com> <5d375e920811121100o15702c64ufb6e367220606058@mail.gmail.com> Subject: Re: [9fans] Do we have a catalog of 9P servers? Topicbox-Message-UUID: 3f83d85a-ead4-11e9-9d60-3106f5b1d025 On Wed, Nov 12, 2008 at 1:00 PM, Uriel wrote: > > 9P doesn't do locking; .u/.l change the protocol. > yes. (well mostly yes - Geoff points out there are some locking semantics in 9P, more correctly 9P doesn't do POSIX locking, .L changes the protocol (.u doesn't make any provisions for locking).) > Of course it would be possible to do locking (ext attrs and other > lunix crud) without changing the protocol, which would have the > advantage of not requiring changes in the dozens of existing 9P > implementations, plus would give one access to such 'features' from > standard cat/echo interface, something which no lunix system can > currently do... > Actually the .L mechanism does it in a way that requires no changes to applications or servers who don't want to do locking. In fact, .L isn't really meant for any existing 9P applications, as I've said previously -- it is a complimentary set of operations intended to function as proxies between Linux systems (or between Linux and a .L remote file server). Servers which don't support an operation (such as locking) respond with an error to Locking requests and the clients are expected to respond gracefully. Access to such changes would not be directly accessible to unmodified programs/systems, however simple proxy gateways could provide a stopgap mapping whatever semantics you want between 9P2010 and 9P2000. However, as I said, this isn't really the intended target of the 9P.L work, its really about establishing a proxy protocol for Linux with a foundation based on 9P. My co-workers and internal customers have constantly attempted to convince me to clean-slate design the protocol and rename it so it doesn't contain any stigma of being associated with Plan 9. But I see that as counterproductive to both communities. Zealots never prosper, or at least they never should prosper. > If I understood erik correctly, .L will even add auth into the > protocol... I guess that only leaves us missing sunrpc for 9P to match > NFS4's beauty. Actually, what I said was is that I was uncertain of how Auth will shake out. It is entirely likely that it can be handled within the context of the existing setup, but since I haven't worked through the implementation yet I'm unsure of what it will look like. The same can be said for all parts of .L actually, all I've done is setup the Linux 9P client to be easily extended (the same work could be used to make an Octopus variant) and look at how many opcodes I may need to reserve to provide proxy functions for Linux VFS calls -- .L will be specified as the implementation is worked out, I wouldn't make too many assumptions about it until that process is (at least mostly) complete. -eric