Hi Nikolay,

I'm very sorry to miss these patches and not give an answer soon...
I totally forgot about them. I'll take a look this week.

Lucas De Marchi

On Mon, Aug 15, 2016 at 9:50 PM, Nikolay Amiantov <ab@fmap.me> wrote:

> These series of patches add more control over how kernel modules directory
> is
> found:
>
> * Add an environment variable which allows to override kernel modules
>   directory;
> * Allow to hardcode several paths which are searched in order for `uname
> -r`
>   subdirectory;
> * Add a configure option to set those paths, instead of hardcoding
>   /lib/modules.
>
> We have used the first patch in NixOS[1] for a long time to point kmod to
> kernel modules. While an environment variable is handy and has been
> solving our
> problems, it doesn't cover all our cases. We have two directories:
>
> * /run/current-system/kernel-modules/lib/modules
> * /run/booted-system/kernel-modules/lib/modules
>
> , which are symlinked to modules for current system configuration (i.e.
> after
> an update) and the one which the system was booted with. It allows us to
> both
> give users ability to install new modules and have their old kernel modules
> accessible until a reboot (which is useful in case of kernel upgrade).
>
> Before those patches the necessary logic (see if kernel modules for current
> kernel version are available in current-system, if not then fall back to
> booted-system) was implemented as a shell wrapper around kmod, which was
> unwieldy and didn't work for applications that use kmod directly. It was
> considered better to move this logic to kmod itself. Also, NixOS uses
> nixpkgs,
> a set of distribution-agnostic packages (which run on e.g. Ubuntu and even
> Mac
> OS X where applicable), so it was necessary to preserve /lib/modules as a
> fallback directory in kmod for it to work on FHS distributions.
>
> As a result a set of generic patches was written that implement necessary
> behaviour while being potentially useful for upstream. Environment
> variable is
> still used in several places (e.g. in automatic generation and running of
> virtual machines) and is useful for us even with the rest of those patches.
>
> A home of those patches can be found on GitHub[2] along with some
> discussion, as can be related NixOS patches and discussion[3].
>
> Big thanks to Shea Levy for the original patch, extensive code review and
> useful advices.
>
> Additionally, while working on those it was discovered that kmod makes use
> of
> PATH_MAX. This constant is considered harmful[4] because it doesn't
> correspond
> to real possible length of filesystem paths. This can be considered a bug,
> but
> in those patches it was decided to follow upstream design decisions
> wherever
> possible and so we also use it here.
>
> [1]: http://nixos.org/
> [2]: https://github.com/abbradar/kmod/
> [3]: https://github.com/NixOS/nixpkgs/pull/17738/
> [4]: http://insanecoding.blogspot.ru/2007/11/pathmax-simply-isnt.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-modules" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Lucas De Marchi