Re: [V9fs-developer] Re: [PATCH 2.6.13-rc3-mm2] v9fs: add fd based transport
On 7/28/05, Ronald G. Minnich 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V9fs-developer] Re: [PATCH 2.6.13-rc3-mm2] v9fs: add fd based transport
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. ron - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V9fs-developer] Re: [PATCH 2.6.13-rc3-mm2] v9fs: add fd based transport
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. ron - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V9fs-developer] Re: [PATCH 2.6.13-rc3-mm2] v9fs: add fd based transport
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/