On Wed, 29 Feb 2012 22:39:01 +0400 Stanislav Kinsbursky <skinsbursky@xxxxxxxxxxxxx> wrote: > Hi, Jeff. > I'll try to explain, how all this namespaces-aware SUNRPC PipeFS works. > The main idea is, that today we have 2 types of independently created and > destroyed but linked objects: > 1) pipe data itself. This object is created whenever kernel requires (on mount, > module install, whatever) > 2) dentry/inode for this pipe. This object is created on PipeFS superblock creation. > This means, any kernel user of SUNRPC pipes have to provide two mechanisms: > 1) Safe call (in per-net operations, if the object is global your case) for > PipeFS dentry/inode pair. This is done this in nfsd4_init_cld_pipe(). > > 2) Notifier callback for PipeFS mount/umount operations. Note: this callback is > done from SUNRPC module (i.e. you have to get nfsd module); this callback is > safe - i.e you can be sure, that superblock is valid. > This is the part I'm having a hard time with. IIUC, the existing examples are fairly clear since you have a 1:1 ratio of objects: a per-net object (the pipe data) that is hooked up to a dentry/inode in a per-net sb. Here though, we don't really have that. We have a global pipe object and I don't see how you can hook that up to multiple dentries/inodes. One possibility is to completely "namespacify" this code -- don't use a global rpc_pipe object and make it per-net instead. If I do that though, then I suppose I'll also need to make all of the nfsd4_client_tracking_ops take a struct net arg as well? Thanks for the help so far... -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
