Re: bin/698: mount uses mount_* for external fs types, umount should too.

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR bin/698; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should
 too.
Date: Sun, 26 Jun 2016 05:59:55 +0000

 Apparently commits don't forward to PRs below 10000 any more (to try
 to reduce accidents, which is reasonable, but annoying in this case...)
 
    ------
 
 From: "David A. Holland" <dholland%netbsd.org@localhost>
 To: source-changes%NetBSD.org@localhost
 Subject: CVS commit: src/sbin/umount
 Date: Sun, 26 Jun 2016 03:40:39 +0000
 Mail-Followup-To: source-changes-d%NetBSD.org@localhost
 
 Module Name:	src
 Committed By:	dholland
 Date:		Sun Jun 26 03:40:39 UTC 2016
 
 Modified Files:
 	src/sbin/umount: umount.c
 
 Log Message:
 If an external unmount program of the form "umount_TYPE" exists
 (e.g. umount_ffs, umount_nfs, etc.) exec it instead of calling
 unmount(2).
 
 Closes PR 698.
 
 Note that the original plan for the PR also involved adding a generic
 facility to store an alternate FS type name in the kernel to use when
 unmounting. This was intended to support filesystems implemented as
 loopback nfs servers, where the visible mount would be of type "nfs"
 pointing at localhost; in that case one would want to be able to
 provide an additional string in order to run an unmount program that
 would both remove that mount and also shut down the loopback nfs
 server daemon.
 
 However, in the 21+ years since the PR was filed, loopback nfs servers
 have gone out of favor (for good reasons) so I don't see any need to
 worry about this case at present, especially since the PR has been
 hanging around this long anyway. (If anyone still has a loopback nfs
 server that they want to use a custom unmount program with, file a new
 PR and assign it to me and I'll deal with it specifically in the nfs
 mount args structure, which unmount already knows how to retrieve and
 examine.)
 
 It is my understanding that filesystems implemented with fuse (which
 has displaced the loopback nfs server model) can already set the FS
 type field so no further work is needed to allow them to use a custom
 unmount program. If this is not the case, please let me know and I'll
 attend to it.
 
 There is no longer any need that I see to provide a general facility
 for storing an alternate filesystem type name.
 
 (One might also ask whether there's any real need for this
 functionality at all any more; this is a fair question, but (a) the
 change is small and (b) there are certainly cases when doing FS
 research where you want a custom unmount program; been there & done
 that.)
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.49 -r1.50 src/sbin/umount/umount.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
 
 
 From: "David A. Holland" <dholland%netbsd.org@localhost>
 To: source-changes%NetBSD.org@localhost
 Subject: CVS commit: src/sbin/umount
 Date: Sun, 26 Jun 2016 03:59:11 +0000
 Mail-Followup-To: source-changes-d%NetBSD.org@localhost
 
 Module Name:	src
 Committed By:	dholland
 Date:		Sun Jun 26 03:59:11 UTC 2016
 
 Modified Files:
 	src/sbin/umount: umount.8
 
 Log Message:
 Document external unmount programs. PR 698. Bump date.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.15 -r1.16 src/sbin/umount/umount.8
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.