Hi,

> To be honest, I'm not sure what we need here. I'm only now (since reading
> this message :-) starting to look at it. What else would we need other
> than:
> 
> 1) an extra vfs entry which takes a mount point and a struct export_args
> 	*, and flags, and does the export update (basically calls
> 	vfs_export)
> 
> 2) a new syscall which takes a path, flags,  and a struct export_args *,
> 	looks up the path, does mount update's securelevel >=2 check,
> 	makes sure you're root, and calls the new vfs call from the vfs
> 	args of	the mount point of the vnode.
> 
> ?? I'll need help to do this. :-)

I think (but I haven't looked too closely at the current code, this is
mostly from memory from ancient times :-)) point 1) above isn't neccessary.
The new syscall should be able to do its work mostly independent of the
filesystem involved.  It might want to check whether it can get a
filehandle of the root node of the exported tree however.

Of course, there are corresponding modifications to mountd needed, too.

> > We once had a version that used a special filesystem type for getting
> > the information from mountd into the kernel, but that got lost during
> > the merge of the 4.4-Lite code :-(.  I hope that this filesystem
> > independence can be resurrected during this process.
> 
> So what did this thing do?

Basically, it did things similar to the above (albeit within the mount
system call).  I would have said, you might want to have a look at
version 1.27 of vfs_syscalls.c, but that one seems to have been deleted
from the CVS tree (is this the first sign of the upcoming anon cvs
service?  I thought that developpers would still have access to the
complete tree after that...).

> Manuel said:
> 
> > And maybe this could solve the problem of clients getting "permission
> > denied"
> > while mountd re-read its exports file ? (see kern/5844 for details).
> 
> I think what we need to do here is either put the nfs server to sleep
> while updating, or actually make the call be able to cancel exports. So
> that mountd would figure out what had changed since last read, and
> add/subtract exports (I think now it just clears all and re-adds).

This is (mostly?) the fault of mountd.  On reload, it first deletes
the export attribute from all exported filesystems, and then reexports
those that are exported in the new exports file.  I'm almost sure that
this has nada to do with the kernel at all.

Feel free to ask for more info.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800