> > > > - don't hardcode AF_MAX in mountd_exports_list.
> > > >   i don't think AF_MAX is appropriate.
> > >
> > > OK.  Should I define a new constant or maybe try to handle dynamically
> > > sized structures?  (Dunno how to do the latter yet.)
> > 
> > have a pointer and do another copyin?
> 
> Oh, true!  I was thinking about returning the exports list to userland,
> and I didn't remember I had removed that functionality from the patch
> (it wasn't available before and it's rather complex to implement).  This
> is the part where a dynamically sized structure may get trickier, isn't it?

the existing practice is doing two calls,
one to get the size of the buffer and another to fill it.

it might be simpler just to push the list to the userland and
migrate to the upcall method. :)

> > > > - i'm not sure if vfsfeature is a good idea.
> > > >   are there any possible users other than nfs?
> > >
> > > I think it will be useful if we move more stuff out of specific file
> > > systems into kernel generic parts.  I don't know yet if this will be
> > > possible at all, but if this is not appropriate...  do you see any other
> > > clean way to initialize the NFS stuff without having to put an '#ifdef
> > > NFSSERVER' in the system code?  That will do the trick, but it is
> > > kind of ugly and doesn't separate the NFS code from the VFS one.
> > > That was the point of this vfsfeatures thing.
> > 
> > can't you do the initialization on the first request?
> 
> Hmm... that could work.  But what about the cleanup routine called
> during unmount?

some kind of lazy g/c, maybe?
i don't think it's a big problem because you can flush all of them
whenever you update the export list.

YAMAMOTO Takashi