On Fri, 26 Feb 1999, Wolfgang Solfrank wrote:

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

Unfortunatly the export lists are kept in fs-specific structures, so we
need to go though the fs for now. :-(

> 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...).

Hmmm. I thought so too.. But it'll be through a different tree as we don't
want to keep two live trees ("real" and anoncvs). Thus I think we'd need
to look in a seperate tree for such versions. We'll see.

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

Kinda. Part of the problem I think is that we don't have a kernel
interface for revoking export permissions other than deleting the overall
export ability.

Take care,

Bill