Sorry if I'm going back over old territory, but I'm a LONG way backed
up in reading my NetBSD related mail (like I still have > 31000 unread
messages...)    I have searched, roughly, anyway, for more messages in
this thread, and couldn't see a resolution - nor does it look like there's
any code in -current one way or the other (that is, neither of the mount(2)
or fnctl(2) man pages seems to have been updated, and there is no fsctl(2)
that I can see, so perhaps this is all still up in the air ...

    Date:        Fri, 16 Sep 2005 07:35:22 -0700
    From:        Chuck Silvers <chuq@chuq.com>
    Message-ID:  <20050916143522.GB25776@spathi.chuq.com>

  | in short, I don't think having file-system-specific stuff in an interface
  | that's intended to control file descriptors makes much sense.

That's certainly true, but it is actually worse than that.   Apart from
overloading fnctl() being just as bad as overloading mount() from a
"niceness" point of view, fnctl() requires an open file, which one assumes,
for this purpose, would be some open file on the file system whose mount
args are to be manipulated.   (Of course, ioctl() is just as bad for the
same reasons.)

This has the obvious (though probably surmountable, if in an ugly way)
problem of how to disambiguate file references in union/overlay/null type
file systems.  In a union whether you get the upper, or lower, file system
is going to depend upon whether the file has been modified or not (via the
union) since the mount was done.   Then null has no files at all, ever,
does it?

OK, by careful choice of exactly which file it is proper to open for this
purpose (maybe the mount point directory - though NFS doesn't guarantee
opening directories is possible, does it?) it would probably be possible
to avoid these kinds of problems, but I wouldn't want to be the one trying
to explain in the man page just how that should be accomplished, let alone why.

The example that clinches it for me however, is when you consider an NFS
(client) mount - a file system mounted form a server that's dead.   To use
fnctl() to adjust the mount options - perhaps to change from hard mount,
to interruptible mount (so as to allow all the hung processes to be killed,
assuming this functionality doesn't remain in mount(2) - but for any other
adjustment that might be wanted) would require opening a file - from the
server that is dead.   Really.

Assuming that it isn't too late, give up on fnctl() for this purpose.
Attempting to "save a system call" is an absurd motivation (that used to
be what people did in pdp-11 days, given the way the trap->sys call
interface was designed - it wasn't much of a rationale even then) - a new
sys call is clearly the right solution.

kre

ps: for what it is worth, which isn't much probably, I also see no problem
with "update" mounts continuing to use the mount() sys call, those need
the exact same set of args as mount() originally needs, for obvious reasons.
Duplicating all of that in the new sys call doesn't seem too productive.