Re: Proposal, again: Disable autoload of compat_xyz modules

[christos%astron.com@localhost (Christos Zoulas)]

In article <201909301931.x8UJVVVE028501%server.cornerstoneservice.ca@localhost>,
John Nemeth  <jnemeth%cue.bc.ca@localhost> wrote:
>On Sep 30,  1:06pm, Michael van Elst wrote:
>} On Mon, Sep 30, 2019 at 12:37:38AM -0700, John Nemeth wrote:
>} 
>} > BTW, modules.conf isn't read by the kernel, it's read by
>} > /etc/rc.d/modules.  Putting anything in there that would have a
>} > lasting effect (i.e. parameters for autoloaded modules) would
>} > require quite a bit of work.
>} 
>} You could just store the parameters in the kernel so that a future
>} autoload will use these instead of or merged with the plist.
>
>     You could do this using the backend code for the proposed
>sysctl.  The question then is how do you know when the .plist is
>changed? Would you attach some kind of a kevent to it?  If so, then
>you need to track the source of the entry in the "blacklist".  If
>it came from the .plist, then upon receiving notification that it
>has changed, then you want to delete the entry.  However, if it
>came from userland via sysctl or is part of the default list, then
>you don't want to delete the entry just because the .plist changed.
>This is starting to get complicated with corner cases.

I am not sure what gets priority here. The command line arguments
in modules.conf or the plist entries (when both exist)? Also while
it is attractive to store the plist next to the module we currently
install 0 plists.  What is the expectation here? That one will use
modload to generate plists or that we are going to put the arguments
in modules.conf? I think that the plists were meant to be static
(as the arguments in modules.conf) and they would take effect only
during load time. The variables in the plists are also supposed to
be module-specific not global.


christos