[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...
Shea Levy
shea at shealevy.com
Mon Mar 26 17:53:07 CEST 2012
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, 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.
>
>>> 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...
More information about the nix-dev
mailing list