NetBSD Problem Report #698

From gnats  Wed Jan  4 15:09:34 1995
Received: from pain.lcs.mit.edu (pain.lcs.mit.edu [128.52.46.239]) by sun-lamp.cs.berkeley.edu (8.6.9/8.6.9) with ESMTP id PAA02856 for <gnats-bugs@sun-lamp.cs.berkeley.edu>; Wed, 4 Jan 1995 15:09:33 -0800
Message-Id: <199501050004.LAA27386@bilbo.dn.itg.telecom.com.au>
Date: Thu, 5 Jan 1995 11:04:54 +1100
From: sjg@zen.void.oz.au
Reply-To: sjg@netbsd.org
To: gnats-bugs@NetBSD.ORG
Subject: /sbin/umount should support umount_*
X-Send-Pr-Version: 3.2

>Number:         698
>Category:       bin
>Synopsis:       mount uses mount_* for external fs types, umount should too.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    darcy
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 04 15:20:03 +0000 1995
>Closed-Date:    Sun Jun 26 06:46:54 +0000 2016
>Last-Modified:  Wed Jul 06 18:50:01 +0000 2016
>Originator:     Simon J. Gerraty
>Release:        1.0
>Organization:
Zen Programming....
>Environment:

System: NetBSD bilbo.dn.itg.telecom.com.au 1.0 NetBSD 1.0 (FIREWALL) #5: Tue Dec 20 15:31:28 EST 1994 root@bilbo.dn.itg.telecom.com.au:/src/sys/arch/i386/compile/FIREWALL i386


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

I note that SunOS's /usr/etc/umount appears to have this facility.

I can certainly add the functionality to umount if you like.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed 
State-Changed-By: cgd 
State-Changed-When: Wed Jul 12 02:25:52 EDT 1995 
State-Changed-Why:  
analyzed. 
the same statement is true of: 
newfs (!! should take a -t to determine type, pass all args on, 
default to type == ffs if no -t given.  probably safe 
to require that 't' should be first arg.  maybe 'T' 
for compatibility with current arguments?) 
fsck (top-level program should parse fstab, be responsponsible 
for picking file systems to check (i.e. pass number stuff), 
and farmint out responsibilities to per-fs programs; 
current fsck should be fsck_ffs.) 
dumpfs (same comments as newfs, mostly, i think.) 

additionally, dump and restore should have equivalents for other file systems, 
as should clri and tunefs, and the current programs should be renamed to 
reflect their FFS-ness. 


Responsible-Changed-From-To: bin-bug-people->cgd 
Responsible-Changed-By: cgd 
Responsible-Changed-When: Wed Jul 12 02:25:52 EDT 1995 
Responsible-Changed-Why:  
"mybug!" 
Responsible-Changed-From-To: cgd->bin-bug-people 
Responsible-Changed-By: cgd 
Responsible-Changed-When: Sat Aug 19 05:55:17 EDT 1995 
Responsible-Changed-Why:  
unclaim. 
State-Changed-From-To: analyzed->feedback 
State-Changed-By: fair 
State-Changed-When: Thu Mar 11 02:48:55 PST 1999 
State-Changed-Why:  
what other things are required for an unmount besides calling the syscall? 
Given that some of the items in here have been acted upon, but most haven't 
in the four years this PR has been open, I'd say this issue was not pressing 
enough to warrant action. Unless feedback arrives to the contrary, this PR 
should be closed. 

From: "Simon J. Gerraty" <sjg@quick.com.au>
To: gnats-bugs@netbsd.org, gnats-admin@netbsd.org
Cc: sjg@quick.com.au, fair@netbsd.org
Subject: Re: bin/698 
Date: Sun, 06 Jun 1999 23:44:18 +1000

 Is it perhaps the case that feedback should be sent to gnats-bugs
 rather than gnats-admin?  If so, the fact that mail requesting
 feedback includes gnats-admin but not gnats-bugs in the cc or reply-to
 list should be considered a bug.

 Clarification either way would be handy.

 --sjg

 > Date: Sun, 06 Jun 1999 23:35:44 +1000
 > From: "Simon J. Gerraty" <sjg@zen.quick.com.au>
 > 
 > I have no idea why the following does not appear in the records for
 > this PR - I'm beginig to think that much of the feedback I've sent
 > over the years has landed in the bit bucket.
 > 
 > --sjg
 > ------- Forwarded Message
 > 
 > Delivery-Date: Mon, 15 Mar 1999 00:55:34 +1100
 > Received: (from uucp@localhost) by zen.quick.com.au (8.8.8/8.7.3) id AAA11087; Mon, 15 Mar 1999 00:55:33 +1100 (EST)
 > Message-Id: <199903141355.AAA11087@zen.quick.com.au>
 > Received: from localhost(127.0.0.1), claiming to be "zen.quick.com.au"
 >  via SMTP by localhost, id smtpd11083a; Sun Mar 14 05:55:26 1999
 > To: fair@netbsd.org
 > cc: sjg, gnats-admin@netbsd.org
 > Subject: Re: bin/698 
 > In-reply-to: Your message of "11 Mar 99 10:51:46 -0000."
 >              <19990311105146.21958.qmail@mail.netbsd.org> 

Date: Mon, 22 Nov 1999 00:53:30 -0800
From: "Erik E. Fair" <fair@clock.org>
To: "Simon J. Gerraty" <sjg@quick.com.au>
Cc: gnats-bugs@netbsd.org
Subject: 698

Yes, in order to have feedback automatically recorded in a PR, one 
puts the PR  number in the subject of a message, and the message must 
be sent to gnats-bugs@netbsd.org

gnats-admin@netbsd.org is nominally read by a human or three, but it 
gets the *full* transaction set of all GNATS PRs, and as such, it is 
difficult for a human to reliably determine if a particular letter 
has been recorded in a particular PR or not.

So, w.r.t. PR 698, why should there be an 
umount_{ffs,nfs,null,union,etc}, other than symmetry with mount? What 
does there need to be done to unmount any of the filesystem that we 
now support, besides calling unmount(2)?

	curious,

	Erik <fair@clock.org>

P.S.	please reply to gnats-bugs@netbsd.org.

Date: Tue, 23 Nov 1999 01:56:21 +1100
From: "Simon J. Gerraty" <sjg@quick.com.au>
To: gnats-bugs@netbsd.org
Cc: fair@clock.org, sjg@quick.com.au, tech-kern@netbsd.org
Subject: Re: PR 698

[cc'd tech-kern in case anyone has any better ideas]

> So, w.r.t. PR 698, why should there be an 
> umount_{ffs,nfs,null,union,etc}, other than symmetry with mount? What 
> does there need to be done to unmount any of the filesystem that we 
> now support, besides calling unmount(2)?

Firstly umount_* need only exist if there is something meaningful for
it to do.  Take snfs as an example (http://www.quick.com.au/Products/sNFS.html)

This filesystem implements NFS over SSL.  The client snfsc does the
talking to the remote machine and tells the kernel to mount an "NFS" fs
using a handle that points at its own socket.  This is a pretty
standard way of implementing "interesting" filesystems without need
for the client OS to support anything but NFS over udp.

In the case of snfs there is no portmap involved - snfsd runs
under inetd and won't grok anything that does not arrive over the
encrypted channel.

This means that on NetBSD, while you can arrange for mount /foo to
work - by invoking mount_snfs, umount /foo will _not_ work as the only
thing the kernel knows about is an NFS mount, and umount(8) because it
"knows" NFS, attempts to send an MOUNTPROC_UMNT rpc to the server -
which is doomed to fail.

On systems like SunOS, Solaris etc which record the mount options
somewhere outside the kernel and will invoke umount_snfs things work
much better.

I understand why NetBSD stores the stuff in the kernel and agree that
it is better.  But we still lose due to the lack of info stored.  On
NetBSD you simply find the pid of the snfsc process and kill it -
shuts down the connection to the server and then dags around until it
can extricate itself from the kernel.  It would be wonderful if all
umount(2)'s took an option to say - "for heaven sake, no further
operations are going to work so just forget about this mount point!"
:-)

I don't claim to know what the correct solution is btw but
one approach I thought of was to add a couple of fields to struct
statfs.  Hmm I see that f_fstypename[] is already there (its been some
years since I looked), which may be part of what I want, but I can't
find where the values for f_type are defined - which I presume is what
the kernel cares about?

Ie. if f_type were set to indicate NFS and f_fstypename could be set
to indicate the real fs type, then the correct umount_foo could be
found.  If that is not the correct use of those fields, then perhaps a
new field is needed.

If we also had say f_mntopts[MNAMELEN] to record the mount options
needed to ensure that umount_foo could do its thing (just the snfsc
pid would do for umount_snfs) then we'd be in business.  Note that the
content of f_mntopts[] need only be meaningful to umount_foo.

Of course one then needs a means of getting the extra info into the
kernel.  

We'd need to either:

1. add an extra arg to mount(2) which could be null.
2. add a struct statfs* (which could be null) to struct nfs_args etc.
3. make the arg passed to mount(2)  something like:

struct dummyfs_args {
	struct statfs *sfs;
	void *data;	/* the real data for sfs->f_type */
};

there may well be a better option that I've not thought of.
I'd expect that each of the above has disadvantages.

Hope that helps.

--sjg

Date: Mon, 22 Nov 1999 10:03:21 -0500
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
To: "Simon J. Gerraty" <sjg@quick.com.au>
Cc: gnats-bugs@netbsd.org, fair@clock.org, tech-kern@netbsd.org
Subject: Re: PR 698 

> It would be wonderful if all umount(2)'s took an option to say -
> "for heaven sake, no further operations are going to work so just
> forget about this mount point!"  :-)

You mean, like umount -f / MNT_FORCE?

Note that MNT_FORCE has been buggy in the past; I've done a fair bit
of work to clean it up, but i'm willing to believe that there are some
bugs lingering.

					- Bill

Date: Tue, 23 Nov 1999 02:09:25 +1100
From: "Simon J. Gerraty" <sjg@quick.com.au>
To: sommerfeld@orchard.arlington.ma.us
Cc: gnats-bugs@netbsd.org, fair@clock.org, tech-kern@netbsd.org
Subject: Re: PR 698 

> > It would be wonderful if all umount(2)'s took an option to say -
> > "for heaven sake, no further operations are going to work so just
> > forget about this mount point!"  :-)
> 
> You mean, like umount -f / MNT_FORCE?

Yes.  I dearly wish Solaris had that :-)

--sjg

State-Changed-From-To: feedback->suspended 
State-Changed-By: sjg 
State-Changed-When: Sat Feb 5 19:01:06 PST 2000 
State-Changed-Why:  
I think I know what needs to be done to address this - but 
won't have any time to work on it for quite a while. 


Responsible-Changed-From-To: bin-bug-people->sjg 
Responsible-Changed-By: sjg 
Responsible-Changed-When: Sat Feb 5 19:01:06 PST 2000 
Responsible-Changed-Why:  
I might as well fix it myself. 
State-Changed-From-To: suspended->feedback 
State-Changed-By: darcy 
State-Changed-When: Sun Feb 16 11:34:29 PST 2003 
State-Changed-Why:  
This has been around for over 8 years.  I think that either someone should 
submit the required changes or we should just close this.  Another can always 
be reopened when there is actual code available. 

From: "Greg A. Woods" <woods@weird.com>
To: gnats-bugs@gnats.netbsd.org (NetBSD GNATS submissions and followups),
  gnats-admin@gnats.netbsd.org
Cc: darcy@netbsd.org, Mail/@proven.weird.com
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
Date: Wed, 26 Feb 2003 01:07:26 -0500 (EST)

 D'Arcy wrote in feedback:
 >  This has been around for over 8 years.  I think that either someone
 >  should submit the required changes or we should just close this.
 >  Another can always be reopened when there is actual code available.

 That reasoning is both bogus and dangerous.

 No bug report should ever be closed just because there's no code to fix
 it available.  The whole point of a bug report like this is to remind
 someone to write the code in the first place!  Please don't go closing
 bug reports without doing anything about them just to get rid of old PRs
 -- there is no valid rationale for that whatsoever.  There's nothing bad
 about old PRs sitting open when they still need eventual attention,
 especially not in a volunteer project.

 If what you meant to say was that you didn't think this PR is valid then
 say that instead.

 (Personally I think this PR is quite valid, and BTW, I also think it's
 best to put this info in the kernel and once upon a time I even had some
 stuff written up about something like this for SySvR4 but I seem to have
 lost it.)

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

From: "D'Arcy J.M. Cain" <darcy@NetBSD.org>
To: "Greg A. Woods" <woods@planix.com>,
  gnats-bugs@gnats.netbsd.org (NetBSD GNATS submissions and followups),
  "Greg A. Woods" <woods@weird.com>, gnats-admin@gnats.netbsd.org
Cc:  
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
Date: Wed, 26 Feb 2003 07:59:06 -0500

 I don't think I was actually saying that they should be closed just because 
 they are old.  That's why out of 10 from 1995 that I started with 9 are still 
 open.  What I do want, though, is to stimulate discussion.  Nothing is going 
 to be closed unless it is either dealt with or there is a concensus that the 
 issue no longer (or never did) exists.

 -- 
 D'Arcy J.M. Cain <darcy@netbsd.org>
 http://www.NetBSD.org/

From: "Greg A. Woods" <woods@weird.com>
To: darcy@NetBSD.org
Cc: gnats-bugs@gnats.netbsd.org (NetBSD GNATS submissions and followups),
  gnats-admin@gnats.netbsd.org
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
Date: Wed, 26 Feb 2003 14:04:12 -0500 (EST)

 [ On Wednesday, February 26, 2003 at 07:59:06 (-0500), D'Arcy J.M. Cain wrote: ]
 > Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
 >
 > I don't think I was actually saying that they should be closed just because 
 > they are old.  That's why out of 10 from 1995 that I started with 9 are still 
 > open.  What I do want, though, is to stimulate discussion.  Nothing is going 
 > to be closed unless it is either dealt with or there is a concensus that the 
 > issue no longer (or never did) exists.

 Good!  OK, I'm glad we're on the same page about that!  :-)

 -- 
 								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>
Responsible-Changed-From-To: sjg->darcy 
Responsible-Changed-By: darcy 
Responsible-Changed-When: Thu Mar 13 13:40:34 PST 2003 
Responsible-Changed-Why:  
Further to discussions on developers, I am taking responsibility for 
making sure that this PR gets closed. 
State-Changed-From-To: feedback->open 
State-Changed-By: perry 
State-Changed-When: Thu Apr 3 17:50:12 PST 2003 
State-Changed-Why:  
Since we are not currently awaiting feedback from the submitter, 
it is more properly listed as "open". 
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
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>
 To: source-changes@NetBSD.org
 Subject: CVS commit: src/sbin/umount
 Date: Sun, 26 Jun 2016 03:40:39 +0000
 Mail-Followup-To: source-changes-d@NetBSD.org

 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>
 To: source-changes@NetBSD.org
 Subject: CVS commit: src/sbin/umount
 Date: Sun, 26 Jun 2016 03:59:11 +0000
 Mail-Followup-To: source-changes-d@NetBSD.org

 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.

State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 26 Jun 2016 06:46:54 +0000
State-Changed-Why:
fixed, finally (modulo the provisos in the commit message)


From: "Simon J. Gerraty" <sjg@juniper.net>
To: <gnats-bugs@NetBSD.org>
Cc: <darcy@NetBSD.org>, <gnats-admin@NetBSD.org>, <netbsd-bugs@NetBSD.org>,
	<sjg@juniper.net>
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
Date: Wed, 29 Jun 2016 15:00:30 -0700

 David Holland <dholland-bugs@NetBSD.org> wrote:
 >  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.

 Thanks.

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

 Indeed - the case that prompted this PR, was NFS running over SSL to
 userland NFS server.  Mount requests authenticated by X509 certs and/or
 2 factor authentication.
 Performance was poor (putting it mildly) but not an important
 consideration.  

 AFAIK the system is still in use today ;-)

From: David Holland <dholland-bugs@netbsd.org>
To: "Simon J. Gerraty" <sjg@juniper.net>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should
 too.
Date: Thu, 30 Jun 2016 01:14:57 +0000

 On Wed, Jun 29, 2016 at 03:00:30PM -0700, Simon J. Gerraty wrote:
  > Indeed - the case that prompted this PR, was NFS running over SSL to
  > userland NFS server.  Mount requests authenticated by X509 certs and/or
  > 2 factor authentication.
  > Performance was poor (putting it mildly) but not an important
  > consideration.  
  > 
  > AFAIK the system is still in use today ;-)

 If so, do we need nfs to provide the option of using an alternate
 filesystem type string?

 -- 
 David A. Holland
 dholland@netbsd.org

From: "Simon J. Gerraty" <sjg@juniper.net>
To: David Holland <dholland-bugs@netbsd.org>
Cc: <gnats-bugs@netbsd.org>, <sjg@juniper.net>
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
Date: Thu, 30 Jun 2016 09:50:57 -0700

 David Holland <dholland-bugs@netbsd.org> wrote:
 > If so, do we need nfs to provide the option of using an alternate
 > filesystem type string?

 That could help - should allow umount to find and
 invoke an appropriate umount_* app.

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: darcy@NetBSD.org
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should
 too.
Date: Tue, 5 Jul 2016 16:05:24 +0000

 On Thu, Jun 30, 2016 at 05:00:01PM +0000, Simon J. Gerraty wrote:
  >  David Holland <dholland-bugs@netbsd.org> wrote:
  >  > If so, do we need nfs to provide the option of using an alternate
  >  > filesystem type string?
  >  
  >  That could help - should allow umount to find and
  >  invoke an appropriate umount_* app.

 Can you point me at what this thing is and exactly what it does (and
 doesn't) do?

 -- 
 David A. Holland
 dholland@netbsd.org

From: "Simon J. Gerraty" <sjg@juniper.net>
To: <gnats-bugs@NetBSD.org>
Cc: <darcy@NetBSD.org>, <gnats-admin@NetBSD.org>, <netbsd-bugs@NetBSD.org>,
	<sjg@juniper.net>
Subject: Re: bin/698: mount uses mount_* for external fs types, umount should too.
Date: Wed, 6 Jul 2016 11:45:11 -0700

 David Holland <dholland-bugs@NetBSD.org> wrote:
 >   >  That could help - should allow umount to find and
 >   >  invoke an appropriate umount_* app.
 >  
 >  Can you point me at what this thing is and exactly what it does (and
 >  doesn't) do?

 It was never open sourced and I've not looked at it since about '98 so a
 bit rusty...

 An external file is used to track the port (and pid) used for each mount
 point - in fact the pid is all we really need, since the client was
 designed to unmount itself atexit() so one way or another an unmount
 request typically resulted in sending SIGTERM to shuffler process:

 :
 # NAME:
 #       umount_snfs - umount an snfs filesystem
 #
 # DESCRIPTION:
 #       This script simply looks for the appropriate process in
 #       'sclnts' and kills it.  The 'snfsc' process does the rest.
 #       This is only necessary on 4.4BSD and other systems which do
 #       not support umount_*.
 #
 # AUTHOR:
 #       Simon J. Gerraty <sjg@quick.com.au>
 #

 That arrangement was sufficiently simple (and main use was on
 SunOS anyway), that the lack of umount_* wasn't a huge issue.

 As noted the snfsc client process (the RPC shuffler)
 can simply be killed to have it cleanup:

 /* DESCRIPTION:
  *      This is an RPC shuffler for passing NFS RCP's via TCP or SSL.
  *      If we decide we need to exit - error or request (SIGTERM) we
  *      dag around until we manage to unmount the fs from the kernel.
  *

 one way or another we end up at

 cleanup()
 {
         do_unmount(80);         /* save us first */
         if (!UnmountRPCdone) {
                 char res = 0;

                 /* do an umnt RPC so server will close down */
                 syslog(LOG_DEBUG, "sending  MOUNTPROC_UMNT %s...",
                        SnfsMntedDir);
                 clnt_call(MntClp, MOUNTPROC_UMNT,
                           xdr_dirpath, &SnfsMntedDir,
                           xdr_void, &res, TIMEOUT);
         }
         syslog(LOG_DEBUG, "exiting...");
 }

>Unformatted:
 Core has decided on the direction for this PR.  From the minutes of the Core
 meeting of 20060316:

 	* version mount syscall
 	* each foo_args struct will have a version field, and an fstype
 	* store the fstype in foo args [first few args are common]
 	* support separate mount programs
 	* don't store the pid internally

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.