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

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

On Mon, Aug 08, 2022 at 07:18:05AM -0700, Paul Goyette wrote:
 > (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.

I think there's a general recognition that it's a useful feature to
have, even though it has real costs (like LOCKDEBUG being so slow);
but on the other hand we're still dealing with the consequences of the
... missteps ... in the initial rollout, even though it was more than
a decade ago.

I can't even remember at this point what half of the technical
showstoppers that we were supposed to swallow were, and I know you've
fixed a lot of them, but there's still at least two(*) big ones left.
Meanwhile the absolute refusal of certain people to listen to concerns
or consider any plans but their own creates a lingering ... lack of
appetite for working on the topic, even though I think all or nearly
all those people have left the project and the circumstances have
changed considerably. This is certainly true for me, and I don't think
I'm the only one. So, mostly, nothing happens.

Note that despite all the calls to remove major pieces of
functionality in the intervening years, I don't think anyone's ever
proposed removing the module system.


(*) I'm thinking of the build scheme and resulting configuration
management problems, and lack of logging/audited of what gets loaded.
[One might think the latter would be simple but it isn't.]

-- 
David A. Holland
dholland%netbsd.org@localhost