On Wed, Aug 17, 2016 at 11:23:13PM -0700, Daniel Campbell wrote:
> Is there a reliable way to test for kernel functionality _before_
> calling modprobe? I think if a service needs certain kernel
> functionality then it should complain -- loudly, if needed -- so the
> admin knows what to do, be it building the feature into the kernel or
> facilitating a module. But I don't think modules should be required. I
> generally don't enable things with M unless some technical situation
> requires it. The only real module I have is the nvidia-drivers module
> which takes care of itself. Everything else is built into my kernels.
 
Yes, and we do that testing. What we do right now is, if that testing
fails, we run modprobe to attempt to load the modules. That causes
"modprobe: command not found" errors for systems that do not have kmod
installed.

I want to change what happens if the testing fails so that it loads the
module, then complains to the admin letting them know that the module
needs to be built in or loaded in /etc/conf.d/modules.

In a future release, I will remove the module loading assuming that you
have everything built in, configured in /etc/conf.d/modules, or your
device manager is taking care of loading the modules.

> lsmod and modprobe can handle modules -- what can be used to target
> kernels that have functionality built-in? Not every system will have
> /proc/config.gz support (though honestly I don't know why you wouldn't
> want that).
> 
> Hiding error or warning messages seems irresponsible to me and could
> lead to confusion. So I guess I'm in favor overall, but don't want to
> see lightweight installs lose anything or become forced to install
> things as modules, as it complicates the kernel configuring process
> needlessly.

There's nothing to do if the kernel has the functionality built in, I
just want to deprecate the behind-the-scenesloading of modules you don't
know we are loading.

William