[Nix-dev] [Nix-commits] SVN commit: nix - r33428 - in nixpkgs/branches/kmod-MODULE_DIR/pkgs: applications/virtualization/virtualbox applications/virtualization/virtualbox/guest-additions build-support/kernel os-specific/l...

[Yury G. Kudryashov]

Shea Levy wrote:

> On 03/26/2012 11:49 AM, Yury G. Kudryashov wrote:
>> Shea Levy wrote:
>>
>>> On 03/26/2012 11:28 AM, Yury G. Kudryashov wrote:
>>>> Shea Levy wrote:
>>>>
>>>>> On 03/26/2012 11:15 AM, Yury G. Kudryashov wrote:
>>>>>> We'll maintain /lib/modules/modversion symlink instead. This way both
>>>>>> module-init-tools and libkmod will work without patches.
>>>>> I really don't like this approach. Given that the kmod tools accept a
>>>>> --dirname=DIR option that allows you to point to the modules
>>>>> directory, why add this additional impurity?
>>>> This way we're closer to what upstream supports.
>>> Upstream supports --dirname=DIR for modprobe. We don't even need a patch
>>> for this.
>>>
>>>> Why do you consider this to be an impurity? You can't have two kernels
>>>> running at the same time anyway. And if you want to load a module from
>>>> another directory, use `-d` or `insmod`.
>>> Because a package might search /lib/modules during install for some
>>> reason. Many kernelPackages do so (and need to be patched to fix this),
>>> and if there were a /lib/modules symlink then you'd have problems
>>> building a kernelPackage for a kernel that's not the currently running
>>> one.
>> There is no /lib/modules symlink. There are /lib/modules/modDirVersion
>> symlinks. And these symlinks are invisible in build chroot. If you build
>> without chroot, you'll have problems on non-NixOS systems anyway.
> 
> Chroot builds are not the default,
(offtopic: why not make them default?)
> and you don't usually need to build
> kernelPackages on non-NixOS. If I'm on linuxPackages_3_2 and I want to
> nixos-rebuild to 3_3, I don't want to have to worry about my newly-built
> kernelPackages accidentally referencing 3_2 still.
I think that every bug should be solved by patching buggy software. In this 
case, buggy kernelPackages.* buildsystem. BTW, could you provide any 
example, please? The logic you've described should be considered a bug in 
any distro, not only NixOS.

> 
>>
>>>> Eelco Dolstra wrote:
>>>>> I dislike introducing a /lib/modules.  What was wrong with using an
>>>>> environment variable to point at the modules tree?
>>>> E.g., next udev version relies on libkmod (not `modprobe`) to load
>>>> modules. This way we can switch a symlink on nixos-rebuild switch. Any
>>>> ideas how to do it with env var?
>>> Patch udev to call kmod_new with the appropriate directory, or patch
>>> libkmod to respect the env var.
>> How do you want to *change* udev's env var on the fly when you do nixos-
>> rebuild switch?
> 
> Why would we want to change udev's env var on the fly? We're not
> changing the kernel on the fly...
An example: add kernelPackages.myModule to the module list without changing 
the kernel. OK, this should not happen often.
-- 
Yury G. Kudryashov,
mailto: urkud at mccme.ru