[Nix-dev] Two approaches to kmod migration

[Yury G. Kudryashov]

Shea Levy wrote:

First of all, let me stress the main difference between module-init-tools 
and kmod. The former is a collection of command line utilities, while the 
latter is a *library* plus a collection of command line utilities provided 
for backwards compatibility.

This difference was the main reason for me to try another approach.

BTW, I moved kmod-MODULE_DIR to kmod-lib-modules. You're welcome to create 
another branch with your kmod migration code.

> On 03/27/2012 01:07 PM, Yury G. Kudryashov wrote:
>> Hi!
>>
>> * Easier to catch buggy kernel module buildsystem.
>> | Just use chroot builds. If you're not root, read the makefile(s)
>> | carefully.
> 
> By this argument, we should just fully follow FHS.
No. I didn't say this.

On the other hand, I see nothing bad in following FHS for *system-wide* one-
instance services. We already have /etc, /bin/sh and /usr/bin/env, why 
/lib/modules is worse than /etc? Non-chroot builds can look into /etc, and 
make strange decisions at configure time.

> But bugs DO happen,
See below (after your item 3).
> 
>> | We'll need the same patches to buildsystem in both cases. The patches
>> | can be accepted upstream and/or shared with mainstream distros.
> 
> Not necessarily. If we use MODULE_DIR, yes, but if we switch to the new
> command line flags that kmod's modprobe supports we won't need to patch
> kmod. We'll need to patch udev if it doesn't supply a similar command
> line flag, of course. The kernel build system can remain as it is now.
See above (about library vs utilities).
> 
>> /lib/modules:
>> =============
>> * No need to patch:
>>    - Kernel buildsystem (removing '-b' key);
>> | I'm pretty sure that the patch will never be accepted upstream
>>    - kmod;
> 
> We won't need to patch kmod.
OK, we'll have to patch either kmod, or every package that links to 
libkmod.so and every package that calls `modprobe`.
> 
>> | Same here
>>    - udev;
>> | Same here, if patch needed (see below)
>>    - more packages to come later.
> 
> If you're allowed to say 'more packages to come later', then I'm allowed
> to say 'more kernelPackages that will hard-code /lib/modules'

The kernelPackages that hard-code /lib/modules cause no problems if you use 
chroot builds. The build will fail, and you'll have to patch the 
buildsystem.

> 
>> | I'm not sure if we need to patch every package, but we definitely need
>> | to ensure that every package using libkmod has MODULE_DIR env var set
>> | to the desired value.
>>    - every shell script that has $(find /lib/modules/`uname -r`)
> 
> Yes, but patching these is a GOOD THING since most of them occur in
> kernelPackage build scripts.
I'm not talking about build scripts, I'm talking about runtime. Sorry that I 
haven't stated this explicitly.

We'll have to patch build scripts in both cases.
> 
>> | I have no well-known example of such script, but kmod has no
>> | `modprobe -l` (this switch was deprecated in module-init-tools).
>>
>> * Easy to switch all running processes to a new module dir.
>> | Rarely needed. It it's hard (impossible?) to reload many modules on the
>> | fly, and it's rather easy to manually `insmod` a few modules.
> 
> 
> Some further thoughts:
>      1. Purity as a general principle has proven value. I believe the
> burden of proof of value is on those who wish to add an impurity.
I think that having /lib/modules/`uname -r` invisible to build scripts adds 
no impurity. The result of each chroot build will depend only on its 
buildInputs, and the runtime behaviour will depend only on its /nix/store 
dependencies and system-wide settings like /lib/modules/`uname -r` symlink, 
/etc, e.t.c..

>      2. The MODULE_DIR approach has precedent and has not, to my
> knowledge, caused any significant problems
As I've stated above, libkmod is a shared library. This means that the 
number of binaries that will need to know $MODULE_DIR will grow as more 
binaries will link to libkmod.so.

>      3. Problems in the MODULE_DIR approach generally come in the form
> of early failures: Build failure, or a boot fails completely on the
> first try. Failures due to a /lib/modules could hide a long time before
> surfacing, such is the nature of impure state
Could you please provide an example of a package such that:
* it leads to an early failure with MODULE_DIR approach;
* it doesn't lead to an early failure with /lib/modules approach with chroot 
builds?

I agree to add "doesn't require chroot builds for early buildsystem errors 
detection" to MODULE_DIR pro's.

BTW, I can provide (currently, theoretical) example of a situation when 
MODULE_DIR approach leads to a hidden failure. Suppose that `foo` executable 
links to libkmod.so, and we've forgotten to wrap `foo` to set MODULE_DIR in 
the wrapper. If `foo` is not critical for boot, then nobody will notice the 
failure. Let me repeat that this situation was not possible with module-
init-tools, but it is possible with libkmod.

>      4. The 'burden' of patching build systems is inherent in a system
> as radical as nix, and is not really that high. We patch shebangs, gcc,
> ld.so, etc. etc... Why is it suddenly a problem for udev, the kernel,
> etc.?
Because we can proceed without these extra patches.
-- 
Yury G. Kudryashov,
mailto: urkud at mccme.ru