Re: [V9fs-developer] Re: [PATCH 2.6.13-rc3-mm2] v9fs: add fd based transport

From: Eric Van Hensbergen
Date: Thu Jul 28 2005 - 13:23:39 EST

On 7/28/05, Ronald G. Minnich <rminnich@xxxxxxxx> 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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at