[systemd-devel] systemd-nspawn trouble

[Tom Gundersen]

On Wed, Apr 22, 2015 at 2:36 PM, Michael Biebl <mbiebl at gmail.com> wrote:
> 2015-04-22 14:26 GMT+02:00 Lennart Poettering <lennart at poettering.net>:
>> On Wed, 22.04.15 14:22, Michael Biebl (mbiebl at gmail.com) wrote:
>>> 2015-04-22 14:14 GMT+02:00 Lennart Poettering <lennart at poettering.net>:
>>> > On Wed, 22.04.15 14:09, Michael Biebl (mbiebl at gmail.com) wrote:
>>> >> 2015-04-22 13:57 GMT+02:00 Lennart Poettering <lennart at poettering.net>:
>>> >> > http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2
>>> >>
>>> >> Not everyone is using networkd or nspawn though, so loading this
>>> >> module for everyone is a bit excessive.
>>> >
>>> > Well, then blacklist the module or don't build it at all.
>>>
>>> That's the wrong way around.
>>
>> Nah, I disagree. We do this for a number of modules now. I mean, we
>
> We currently do this static loading for unix, ipv6 and autofs4.
>
>> load tons of modules automatically, even if you don't use them. For
>> example, my laptop always loads the bluetooth modules, even though I
>> never used bluetooth.
>
> Those are all loaded on demand, not statically. I.e. we don't load the
> bluetooth module for each and every user.

We never require the admin to explicitly opt-in to loading any modules
for the functionality we use. For hardware drivers, modules are
unconditionally loaded when the hardware exists, for other modules the
kernel is usually able to load them on demand (filesystems, netdevs,
...). In the cases where the kernel is not able to load modules
on-demand I agree with Lennart that it makes the most sense to simply
unconditionally load the modules. If this is undesirable the solution
should be to teach the kernel to auto-load the modules, not to expect
the admin to figure out that explicit loading is required, IMHO.

Cheers,

Tom