[Nix-dev] Two approaches to kmod migration

[Yury G. Kudryashov]

Shea Levy wrote:

It seems that we repeat the same arguments, and neither of us think that 
arguments of other side are serious enough. Therefore, I propose the 
following:
* I upgrade udev in my branch;
* you create another branch, and reach the same state (bootable system with 
latest udev).

Then we ask others to review both branches. If nobody will reply during some 
period of time (say, a week), we continue our discussion.

What do you think about this?

I will not answer in this thread until someone will write a branch based on 
MODULE_DIR approach with kmod and latest udev that will be able to boot on 
my system.

> On 04/04/2012 02:42 PM, Yury G. Kudryashov wrote:
>> Shea Levy wrote:
>>
>>>> /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`.
> 
> OK, but if we need to patch kmod the patch is extremely simple. Just
> modify kmod_new so that when dirname is NULL use MODULE_DIR instead of
> /lib/modules. Problem solved for all utilities that use kmod, no need
> for wrapper scripts or anything.
How an unwrapped binary will get MODULE_DIR environment variable? This is my 
main question. Patching libkmod is easy, but wrapping every binary that 
links to libkmod isn't.

> 
>>>> | 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.
> 
> Not everyone can use chroot builds. Not everyone wants to use chroot
> builds. Chroot builds can be modified (e.g. I could choose to include
> /lib in my chroot). Unless Eelco says otherwise, I think it's a really
> bad idea to say that ANY package in nixpkgs or any nixos evaluation
> requires chroot dirs. There are many specialized features that we
> purposely keep out of nixpkgs (e.g. dynamic import, use of <> path
> resolution, etc.) to keep it working on the widest variety of systems,
> and I don't think a minor patch to a single library is enough reason to
> break compatibility for some systems.

Only *packagers* will have to use chroot builds, or carefully read 
Makefiles. *Users* will be able to use non-chroot builds, because they will 
get patched sources.

>>>> | 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.
> 
> Can you point me to a script that uses $(find /lib/modules/`uname -r`)
> that's actually doing the right thing?
Currently, no. But $(find /lib/modules/`uname -r` -name \*.ko\*) seems to be 
reasonable replacement for `modprobe -l`.

>>> 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..
> 
> Again, I don't accept this dependency on chroot builds. This is
> absolutely an impurity, otherwise why would you want it? MODULE_DIR
> provides a way to explicitly pass the location of the modules to
> programs that need it, and using /lib/modules lets those programs make
> assumptions about system state that aren't explicitly passed to them. If
> /lib/modules truly resulted in no impurities then it would have no
> advantages to MODULE_DIR.
More precise statement: bad buildsystems can be easily catched by chroot 
builds. Good buildsystems do not depend on /lib/modules/`uname -r`, thus 
output of a goo buildsystem does not depend on /lib/modules/* symlinks.

>>>       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.
> 
> Unless we just modify kmod, then all such binaries will work correctly
> unless they stupidly call kmod_new with "/lib/modules" instead of NULL.
Unless they have not MODULE_DIR environment variable.
-- 
Yury G. Kudryashov,
mailto: urkud at mccme.ru