[pnfs] pnfsd export/callback API [was Re: [PATCH] pnfsd: Notify device ID changes]

[J. Bruce Fields]

On Fri, Jun 13, 2008 at 02:11:28PM -0700, Marc Eshel wrote:
> "J. Bruce Fields" <bfields at fieldses.org> wrote on 06/13/2008 01:25:07 PM:
> 
> > "J. Bruce Fields" <bfields at fieldses.org> 
> > 06/13/2008 01:25 PM
> > 
> > To
> > 
> > Marc Eshel <eshel at almaden.ibm.com>
> > 
> > cc
> > 
> > Benny Halevy <bhalevy at panasas.com>, pNFS Mailing List 
> <pnfs at linux-nfs.org>
> > > I think it needs to be the superblock, can you think of a better 
> place?
> > 
> > Might be OK.  Or maybe it could just be a global?
> 
> Then you need an exported symbol which also create a dependency on nfsd by 
> the fs.

No, it'd be a global belonging to the filesystem's module.  So

	struct pnfs_callbac_ops *my_pointer_to_pnfs_cbs;

or something.

> > Or if you know you only need to use it while you hold a layout (for
> > example) then it might make sense to put it there.
> > 
> 
> Maybe we can pass it to the fs when it calls the export operations that 
> checks if the fs supports pNFS but we still don't know when we can not use 
> it anymore.

Right.

> 
> > > 
> > > > 
> > > > What are the natural places in the filesystem code where the 
> filesystem
> > > > a) knows it may need to do pnfs callbacks, and b) knows it no longer
> > > > needs to do callbacks?
> > > 
> > > I prefer not to have to keep track of the need for the calls,
> > 
> > So there's not some object (layout, or something else?) whose lifetime
> > naturally bounds the time when you'd need the callbacks?
> 
> no

It's also a question of how you want the filesystem to work--do you want
it to *always* make these callbacks to nfsd, regardless of whether
anyone's using pnfs or not?  Maybe that's OK.

--b.