On Wed, Nov 12, 2008 at 1:00 PM, Uriel <[EMAIL PROTECTED]> 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
