linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Van Hensbergen <ericvh@gmail.com>
To: "Ronald G. Minnich" <rminnich@lanl.gov>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org,
	v9fs-developer@lists.sourceforge.net, akpm@osdl.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [V9fs-developer] Re: [PATCH 2.6.13-rc3-mm2] v9fs: add fd based transport
Date: Thu, 28 Jul 2005 13:14:38 -0500	[thread overview]
Message-ID: <a4e6962a0507281114378a8d63@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0507280819210.12285@enigma.lanl.gov>

On 7/28/05, Ronald G. Minnich <rminnich@lanl.gov> wrote:
> 
> 
> On Thu, 28 Jul 2005, Christoph Hellwig wrote:
> 
> > Couldn't the two other transports be implemented ontop of this one using
> > a mount helper doing the pipe or tcp setup?
> 
> that's how we did it in the version we did for 2.4. I don't see why not.
> 

I strayed away from doing it this way originally for two reasons -
perhaps both are not really valid:

a) I really disliked requiring a helper application to mount a file
system.  I really wanted to be able to boot a diskless system with no
initrd and have just 9P serving root.  I figured if I could enable
people to use 9P without having a helper app, it would be used by more
folks -- of course the need for things like DNS resolution, etc. that
helper apps tend to provide sort of invalidates this piece of things.

b) I was concerned with additional copy overhead - one of the other
transports which isn't published yet uses shared memory (to
virtualized partitions) and it just seemed easier to deal with that in
the kernel rather than punting to a user-level application -- so in
short, I figured keeping the transport modules in the kernel made
sense.  Of course, that doesn't have anything to do with the socket
interfaces being in the kernel -- I don't think there is any
additional copy overhead when using an fd versus a sock.

That being said, many things may be much easier with a user-level
helper - have user level security modules for instance.

I guess I'm not opposed to removing the TCP and named-pipe transports
if folks think that's a reasonable thing to do -- but I'd like to keep
the modular transport infrastructure to support things like the shared
memory transport.  Of course we also need to get our act in gear and
make a reasonable mount-helper application available -- we've got
three versions right now and two of them rely on the Plan 9 from User
Space packages.

Anybody against taking this path?

         -eric

  reply	other threads:[~2005-07-28 18:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-28 13:57 [PATCH 2.6.13-rc3-mm2] v9fs: add fd based transport ericvh
2005-07-28 14:17 ` Christoph Hellwig
2005-07-28 14:19   ` [V9fs-developer] " Ronald G. Minnich
2005-07-28 18:14     ` Eric Van Hensbergen [this message]
2005-07-28 14:38 ` [V9fs-developer] " Russ Cox

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=a4e6962a0507281114378a8d63@mail.gmail.com \
    --to=ericvh@gmail.com \
    --cc=akpm@osdl.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rminnich@lanl.gov \
    --cc=v9fs-developer@lists.sourceforge.net \
    /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).