[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