[ On Saturday, March 15, 2003 at 00:19:44 (-0800), Simon J. Gerraty wrote: ]
> Subject: Re: /sbin/umount should support umount_* (PR#698)
>
> Sure, but unless PR#698 has been fixed recently, if you mount something like 
> snfs (mount_snfs), the fstype will be reported by the kernel as "nfs"
> and invoking umount_nfs will definitely not be useful.
> That's the crux of this PR.

So, the real problem here is that with the current design and
implementation of the kernel every unique filesystem _MUST_ have a
unique fstype name (and thus against the current the implementation of
snfs is "broken", i.e. incomplete).

I suppose I didn't fully realize that your mount_snfs would result in
the f_fstypename still being just "nfs" -- and by the time I got around
to actualy examining f_fstypename I was certainly assuming it would be
using its own unique string....

> Anyway the problem then was that as far as the kernel knows, its
> an NFS mount.  More data is needed in order for
> the correct umount_* to be invoked.  That's what the PR's is for ;-)

Yes, and I would suggest that data is "snfs" (or something else similar
that's unique amongst existing filesystem types) as the fstype name.

Perhaps a slightly more flexible solution would be to allow new
filesystem type names to be registered at runtime (eg. with sysctl) for
those filesystems which migh allow variant types, in combination of
course with implementation of the suggested umount(1) wrapper which
invokes /sbin/umount_FSTYPE.

Either way the result is your mount_snfs would register the PID and
mount point of the associated process in, say, /var/run/mount_snfs.pid
and your new umount_snfs would signal that PID either before (or after,
as appropriate) calling umount(2).

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>