On Fri, 26 Feb 1999, Wolfgang Solfrank wrote:

> > Looks okay to me. While you're at it, maybe you can split off exporting
> > filesystems from the mount() system call, i.e. introduce an exportfs()
> > system call (as SunOS had) :-) Overloading the mount call with this is
> > kind of ugly.

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

> Well, this probably makes sense.  However, the main problem is that mountd
> really only groks the ufs filesystem.  So any other filesystem that wants
> to be exportable has to resemble the mount arguments of the ufs filesystem.
> 
> 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?

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

The latter's beyond what I can do at the moment.

Take care,

Bill