[Nix-dev] Two approaches to kmod migration

[Shea Levy]

On 03/27/2012 01:07 PM, Yury G. Kudryashov wrote:
> Hi!
>
> Yesterday I've created a 'kmod-MODULE_DIR' branch in nixpkgs and nixos svn.
> Then Eelco Dolstra and Shea Levy told me that they do not like the proposed
> change.
>
> I've tried to create a small summary of the thread. Shea, could you correct
> me if I'm wrong, please?
>
> Pros of MODULE_DIR and /lib/modules approaches
> ==============================================
> (with comments by Yury Kudryashov)
>
> MODULE_DIR:
> ===========
> * Different processes can use different /nix/store/*modules* dirs.
> | Since we have one kernel loaded at every moment, this shouldn't be needed.
> | If someone really needs this, he can use '-d' flag.
>
> * 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. But bugs DO happen, 
and will continue to happen as long as these hard-coded paths are 
reliable. Given that we have this great system for installing packages 
in directories pretty much guaranteed to be unique to that build, why 
not take advantage of it?

> | 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.

> /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.

> | 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'

> | 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 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.
     2. The MODULE_DIR approach has precedent and has not, to my 
knowledge, caused any significant problems
     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
     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.?