Re: Module autounload proposal: opt-in, not opt-out

[Paul Goyette <paul%whooppee.com@localhost>]

On Mon, 8 Aug 2022, Martin Husemann wrote:

> On Mon, Aug 08, 2022 at 09:24:28AM -0400, Greg Troxel wrote:
> > Given where we are, do you really mean
> >
> >   we should withdraw every module from autoload that does not have a
> >   documented test result, right now?
> >
> > It seems far better to have them stay loaded than be unavailable.
>
> I'm not sure (and given Taylor's reply it is not easily doable anyway).
>
> However, I find the idea of offering auto-loadable modules which we do
> not fully trust kind of disturbing.
>
> On the other hand we have not heard[1] of many crash reports that are due
> to auto-unload, so maybe the problem is not that bad after all and we could
> fix the broken ones when we catch them.
>
>
>
> Martin
>
> 1: which might be just because the feature not being exercised very often

I suspect that modules are not being used very much.  After all, we
include nearly everything in GENERIC kernels, so there's rarely any
need to load modules.  (The major exception being dtrace, IIUC, and
that's almost exclusively for developers.)  I'm probably one of the
most ardent proponents of modules, regularly running a completely
stripped-out kernel (minimal built-in module code).

I'd like to suggest an alternative proposal: have a new sysctl(8)
variable that controls whether the default is opt-in vs opt-out.
Setting opt-in would require a module to explicitly return 0 from
its modcmd(AUTOUNLOAD) routine, while setting opt-out would accept
either 0 or ENOTTY (the current behavior).  I'm not sure which
would be the best default (and won't argue, regardlesss of which
default is selected), but the ability to retain the current opt-
out behavior is important to me, and might lead to more/better
testing (albeit mostly ad-hoc vs formal testing).

(personal note)
It really seems to me that the current module sub-systems is at
best a second-class capability.  I often get the feeling that
others don't really care about modules, until it's the only way
to provide something else (dtrace).  This proposal feels like
another nail in the modular coffin.  Rather than disabling (part
of) the module feature, we should find ways to improve testing
the feature.


+--------------------+--------------------------+----------------------+
| Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:    |
| (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul%whooppee.com@localhost    |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette%netbsd.org@localhost  |
| & Network Engineer |                          | pgoyette99%gmail.com@localhost |
+--------------------+--------------------------+----------------------+