> > - 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?

> > - 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?

> > - what's the point of del_exports in send_umntall?
> 
> send_umntall is the SIGTERM signal handler.  Shouldn't mountd(8)
> unexport all file systems on exit?  If not, why not?

i'm not sure if it should.
it makes stopping mountd on a running server somewhat fragile.
on the other hand, i can't think of any benefits of it.
anyway, as it isn't related to the rest of the patch, it should be
omitted at this point, IMO.

YAMAMOTO Takashi