9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Uriel <uriel99@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] 9P vs. FUSE
Date: Fri, 10 Aug 2007 21:16:30 +0200	[thread overview]
Message-ID: <5d375e920708101216y225ca5e5oa06270d90e6d4271@mail.gmail.com> (raw)
In-Reply-To: <a4e6962a0708100645o40d78c12lc3fc162cdbb22c45@mail.gmail.com>

> However, it was decided at the last IWP9 that we had probably taken
> the wrong approach with 9p2000.u and it would probably have been
> better to extend 9p with new operations that had different
> syntax/semantics from standard 9p as these would be easier to filter
> out.  I'm currently playing with a new design in my copious spare
> time.
>
> It was further suggested by some that a better approach on Linux/UNIX
> would have been to take what we know from 9p and design a protocol
> specific to the VFS (similar to FUSE but capable of transparent
> network, etc.)
>
> Some of the recent v9fs effort has been looking at 9p for
> paravirtualized file system access between hosts using shared memory
> transports.   Much initial work has been done using 9p and 9p2000.u,
> but requests for more comprehensive solutions have been requested by
> customers/interested-parties with full support for Linux capabilities.
>  As such, there may be a foray into providing something along the
> lines of a new set of extensions supporting all Linux VFS operations
> (perhaps I'll call it 9p2000.l)

Strange, this is not what I remember from IWP9 at all. What I remember
is that pretty much all requirements people had could be accommodated
*without* changing the existing 9p2000 protocol by using conventions
on special attach names to provide access to extra required
functionality or other such tricks (the exception was the idea of how
to group messages, which unfortunately nemo seems to have discarded
but I still think is so far the only real improvement 9p might need,
and it could be largely backwards compatible)

Of course, my memory could be wrong, but it would be really sad to see
yet another 9p variant pop up after the .u debacle when I think the
consensus was clear that 9p could handle just fine pretty much
everything everyone wanted (again with the exception of the message
grouping for high latency links).

In any case, it would be nice if people considering changes to the
protocol could be a bit more open about it so we could have some
discussion about how much sense it makes, and we could avoid a repeat
of the waste of time and effort with .u.

Best wishes

uriel


  parent reply	other threads:[~2007-08-10 19:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-10 11:42 Enrico Weigelt
2007-08-10 11:57 ` Skip Tavakkolian
2007-08-10 12:19 ` Iruata Souza
     [not found] ` <2d66a95ea087868174cfdc519a48a2d7@9netics.com>
2007-08-10 12:33   ` Enrico Weigelt
2007-08-10 12:36     ` erik quanstrom
2007-08-10 12:42       ` Lucio De Re
     [not found]     ` <22bce9d3afa44ed70b739ea77d5d8046@quanstro.net>
2007-08-10 12:48       ` Enrico Weigelt
2007-08-10 13:18         ` erik quanstrom
     [not found]         ` <f17c25af999bb93211e069e6109bb154@quanstro.net>
2007-08-10 13:36           ` Enrico Weigelt
2007-08-10 13:42             ` andrey mirtchovski
2007-08-10 13:44             ` erik quanstrom
2007-08-10 13:45     ` Eric Van Hensbergen
2007-08-10 15:51       ` ron minnich
2007-08-10 16:32         ` Latchesar Ionkov
2007-08-10 16:39           ` Eric Van Hensbergen
2007-08-10 18:16           ` ron minnich
2007-08-10 18:25             ` Latchesar Ionkov
2007-08-10 18:35               ` Eric Van Hensbergen
2007-08-10 19:16       ` Uriel [this message]
2007-08-10 19:21         ` ron minnich
2007-08-10 19:29           ` Charles Forsyth
2007-08-10 21:57             ` ron minnich
2007-08-10 19:29         ` Eric Van Hensbergen
2007-08-10 19:32         ` Latchesar Ionkov
2007-08-10 19:02     ` Uriel
2007-08-10 19:21       ` Charles Forsyth
2007-08-10 19:26         ` erik quanstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5d375e920708101216y225ca5e5oa06270d90e6d4271@mail.gmail.com \
    --to=uriel99@gmail.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).