Re: CVS commit: src/sbin/umount

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 25 Mar 2025 15:01:11 -0400
    From:        "Christos Zoulas" <christos%netbsd.org@localhost>
    Message-ID:  <20250325190111.E3226FBE1%cvs.NetBSD.org@localhost>

  | GitHub/31: Ricardo Branco: Add -d flag to umount to detach vnds,

Why would we do this for vnd devices, and not cgd, raidframe, ccd, ... ??

For that, it also seems like it would be worth having a generic
"unconfigure" ioctl command, which could be used by all these, and
more, rather than every one of them having an ioctl of their own.
It isn't as if what is needed to be conveyed as part of an unconfigure
request is particularly device dependent (unlike configuring it).

If no-one has any objection to that, I will (after a little research)
invent a new ioctl, implement it in the relevant drivers (or some of
them at least, the driver change should be truly trivial, if I miss
any, anyone could do the others) and then make umount use that one,
so that any unconfigurable device can be unconfigured (if not still
in use by something else, of course).   And umount would never need to
be changed again as more similar devices are created over time, just
the common ioctl implemented as part of that new device - it wouldn't
need to make a new one of its own.

The various *ctl (or *config) (8) apps could be changed to use the
new ioctl, or not, that's not too important - if they all were, then
the code for the currently existing ones in the kernel could conceivably
be moved into a COMPAT_NN module somewhere, but since all that would be
are the few lines of code that recognise the ioctl and call the actual
unconfig function, that's probably not worth the bother, they can just
stay forever.

Opinions?

kre