>    If I _were_ to modify /sbin/mount and umount to use an mtab file for
>    recording mount options and fstype thus making umount_* possible.
> 
> That would be undesirable.  As you pointed out yourself, there's
> another solution to this.  The reason for keeping this info in the kernel
> is so that it's always correct, even when root in mounted read-only.

Ummm what solution did I point out?  Retrieving the sockaddr from the
kernel was the only thing I could think of and while that solves _my_
requirement it may not be enough for other external filesystems.
Also while it could be added for NetBSD, other *NIX would need to
stick with the current method as adding/modifying system calls is a
bit harder without kernel source.
Still, I take your point about the read-only root.

> BTW, I'm a little confused.  Are you having inetd fork a separate
> process for every mount, and creating server processes when a mount is
> requested?  If that's the case, you could instead have a master daemon

Yep that's what it does.  Keep in mind that this is aimed at a very
tight environment - basically a bunch of bastion hosts with _no_ NFS
support in their kernel allow a _single_ machine to mount their root
fs via TCP but only after authentication via one-time password.  The
NFS server code itself is from the Linux one and allows all mounted
filesystems to be exported as one.  So each ``server'' machine is only
ever dealing with a single mount request.  Thus inefficiency is not a
major concern.  Also when using UDP transport only a single process
runs for any number of mounts.

> that accepts both mount and unmount requests, forks the servers, and
> remembers which processes are serving which mount requests, so they can
> be shut down later, using a signal or whatever.

Originally I did not follow that path as it would require the server
telling the client to go away - as the UMNT RCP would (as far as the
client RPC shuffler is concerned) be sent out-of-band.  It would thus
be necessary for the server to tell its client to ``go away''.

As it turned out, I had to add that ``go away'' facility later when
I added the facility for the server to require a one time password
from the user issuing the mount request.  In this mode the client RPC
shuffler cannot automagically re-etsablish its connection after a
server re-boot, so it unmounts its filesystem and exits.  To reduce
the trauma, the server in "auth" mode sends a ``go away'' RPC when it
is shutting down.  So, perhaps I should re-visit the basic model at
the server end...

Thanks for the input.

--sjg