Subject: Re: bin/698: /sbin/umount should support umount_*
To: Chris G Demetriou <Chris_G_Demetriou@lagavulin.pdl.cs.cmu.edu>
From: Simon J. Gerraty <sjg@zen.void.oz.au>
List: netbsd-bugs
Date: 02/16/1995 23:47:42
> > >Description:
> > When implementing a new remote filesystem type, the mount_<type> facility
> > supported by /sbin/mount is extremely useful.
> > However, it would be even better if /sbin/umount provided the same feature.
> 
> could you please explain in a bit more depth why it's useful?  (I
> can't see it immediately, and while i agree it's useful for
> orthogonality...)

Chris, 

I had a very quick look at implementing this the other day...
I stopped because I dicovered that it requires much more than a simple
mod to /sbin/umount.

Background:

I'm about ready to release my modified User land NFS server and client.
Its mainly aimed at firewall environments so the server just runs from
inetd and portmappers are not involved.  Depending on the transport in
use the UMNT RPC must be sent to the the server at the port listed in
the mount options or to the local client which is shuffling RPC's to
the server.

Ideally, umount should be able to find out from the kernel the
sockaddr that it is using.  Under SunOS at least, I'm not aware that
this is possible.  However under SunOS all the mount options are
stored in /etc/mtab and are passed to umount_* by umount.

So my umount_unfs (just a symlink to mount_unfs), can process the
options and determin the transport and port to be used.  If a local
client is expected to be running it looks up its port number in a
separate file... sad but necessary.

The problem for NetBSD: 

The reason I halted my efforts the other day was that I could not see
where umount can find the options given to mount.  I didn't see any
evidence of an mtab file...

It can't just look for mntpt etc in fstab as the mount may have all
been specified via command line.  As far as I can tell, umount
only has access to the mount flags passed to the kernel.

If this really is the case, then umount would have no way of knowing
that an external fs type is in use as UNFS at least just passes "nfs"
to the kernel when doing the mount.  Indeed getfsstat(2) implies that
only 3 filesystem types are supported.

So... it looks like umount_* actually requires a complete re-work of
fs mounting.

If I _were_ to modify /sbin/mount and umount to use an mtab file for
recording mount options and fstype thus making umount_* possible.
Would you guys want to incorporate it into the tree - or would I be
wasting my time?

Fortunately just sending a SIGTERM to my client will cause it to
unmount everything before exit so it is currently usable under
NetBSD...