[Nix-dev] Two approaches to kmod migration

Yury G. Kudryashov urkud.urkud at gmail.com
Tue Mar 27 19:07:13 CEST 2012


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.

| We'll need the same patches to buildsystem in both cases. The patches can
| be accepted upstream and/or shared with mainstream distros.

/lib/modules:
=============
* No need to patch:
  - Kernel buildsystem (removing '-b' key);
| I'm pretty sure that the patch will never be accepted upstream
  - kmod;
| Same here
  - udev;
| Same here, if patch needed (see below)
  - more packages to come later.
| 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`)
| 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.
-- 
Yury G. Kudryashov,
mailto: urkud at mccme.ru



More information about the nix-dev mailing list