Re: [9fans] Do we have a catalog of 9P servers?



On Wed, Nov 12, 2008 at 1:00 PM, Uriel <uriel99@xxxxxxxxx> 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

.



Relevant Pages

  • [git patches] ocfs2 update
    ... protocol change, so it'd be nice to see this upstream with all the other ... ocfs2: Negotiate locking protocol versions. ... locking semantics of the file system using the protocol. ... +struct dlm_protocol_version { ...
    (Linux-Kernel)
  • Re: FreeBSD 5.5 persistent crashing
    ... I do not know right locking ... retrieving revision 1.11.2.1 ... Thanks Kostik, ...
    (freebsd-hackers)
  • Re: XQuery (and XML) vs LISP
    ... locking" has already been implemented in major databases such as DB2 ... and SQL Sever (see Mohan's ARIES protocol, ... protocol that is described in Mohan's 1990 paper. ...
    (comp.databases.theory)
  • Re: ethercons: ethernet console driver for 5-current
    ... >>paper this summer on a Linux ethernet console driver, ... >>implementing ethernet console support for FreeBSD. ... I wanted to minimize the amount of transient protocol state. ... notion to get a session key. ...
    (freebsd-current)
  • Re: [PATCH] mmu notifiers #v5
    ... design and it requires zero additional locking anywhere (nor linux VM, ... GRU a lot slower _especially_ on your numa systems. ... It populates TLB entries on demand ...
    (Linux-Kernel)