[gentoo-dev] rfc: openrc using modprobe directly to load kernel modules

[gentoo-dev] rfc: openrc using modprobe directly to load kernel modules

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

All,

I'm starting this thread because of the bug I'm citing below [1].

The issue is that some systems do not use kernel modules, and do not
have kmod installed at all. Since we run modprobe unconditionally in a
few places in OpenRC, we always generate "modprobe: command not found"
errors on systems which are set up like this.

If you read the bug, the proposed fixes have been a bit controversial in
the past. Since we have the "want" dependency now, I would like to
propose a different fix.

1. all of the current openrc services that use modprobe should have
"want modules" in their dependencies.
2. After this is done, these services should still attempt to load the
modules if necessary, but they should complain to the user about it and
recommend either building these modules in or using /etc/conf.d/modules
to configure them so they are loaded by the modules service.
3. Then, at some point in the future, OpenRC could remove the modprobe
commands.

Thoughts?

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=342313

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] rfc: openrc using modprobe directly to load kernel modules

[james]

On 08/17/2016 12:54 PM, William Hubbs wrote:
> All,
>
> I'm starting this thread because of the bug I'm citing below [1].
>
> The issue is that some systems do not use kernel modules, and do not
> have kmod installed at all. Since we run modprobe unconditionally in a
> few places in OpenRC, we always generate "modprobe: command not found"
> errors on systems which are set up like this.
>
> If you read the bug, the proposed fixes have been a bit controversial in
> the past. Since we have the "want" dependency now, I would like to
> propose a different fix.
>
> 1. all of the current openrc services that use modprobe should have
> "want modules" in their dependencies.
> 2. After this is done, these services should still attempt to load the
> modules if necessary, but they should complain to the user about it and
> recommend either building these modules in or using /etc/conf.d/modules
> to configure them so they are loaded by the modules service.
> 3. Then, at some point in the future, OpenRC could remove the modprobe
> commands.
>
> Thoughts?
>
> William
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=342313
>

As a gentoo user, developing a gentoo framework for rapid and frequent 
(and yes unattended installs) on heterogeneous gentoo clusters, I think 
Comment 8 says it all, repeat here for convenience::

Comment 8 <partial>
"There are people for which having module-init-tools is just a waste of 
space/time/build; we force it already enough with the profile, you don't 
want to test for it everywhere, you don't want to hide output, tell me 
what you want, so I can make it, but I don't want module-init-tools 
forced in on LXC/xen/monolithic installs."

+1,

I rarely use loadable kernel modules, for my cluster builds. In fact I 
migrating to a large variety of complete stage-4 images for gentoo 
clusters, that are very use specific, highly tuned and minimized, 
including openrc, the base profile and old codes necessary for the work 
at hand, for the target hardware node.


hth,
James

Re: [gentoo-dev] rfc: openrc using modprobe directly to load kernel modules

[Daniel Campbell]

[-- Attachment #1.1: Type: text/plain, Size: 2383 bytes --]

On 08/17/2016 09:54 AM, William Hubbs wrote:
> All,
> 
> I'm starting this thread because of the bug I'm citing below [1].
> 
> The issue is that some systems do not use kernel modules, and do not
> have kmod installed at all. Since we run modprobe unconditionally in a
> few places in OpenRC, we always generate "modprobe: command not found"
> errors on systems which are set up like this.
> 
> If you read the bug, the proposed fixes have been a bit controversial in
> the past. Since we have the "want" dependency now, I would like to
> propose a different fix.
> 
> 1. all of the current openrc services that use modprobe should have
> "want modules" in their dependencies.
> 2. After this is done, these services should still attempt to load the
> modules if necessary, but they should complain to the user about it and
> recommend either building these modules in or using /etc/conf.d/modules
> to configure them so they are loaded by the modules service.
> 3. Then, at some point in the future, OpenRC could remove the modprobe
> commands.
> 
> Thoughts?
> 
> William
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=342313
> 
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.

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.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] rfc: openrc using modprobe directly to load kernel modules

[Consus]

On 23:23 Wed 17 Aug, Daniel Campbell wrote:
> 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).

Well,

	$ ls /sys/module

if we are talking about modules. Built-in modules are also listed there.

Re: [gentoo-dev] rfc: openrc using modprobe directly to load kernel modules

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]

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



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]