Linux-Modules Archive on lore.kernel.org
 help / color / Atom feed
From: Lucas De Marchi <lucas.de.marchi@gmail.com>
To: Nikolay Amiantov <ab@fmap.me>
Cc: linux-modules <linux-modules@vger.kernel.org>,
	Shea Levy <shea@shealevy.com>
Subject: Re: Improvements in search of kernel modules directory
Date: Fri, 11 Nov 2016 00:13:28 -0200
Message-ID: <CAKi4VAL4907RvRJFkUiyVEK3Qjd8EqvBus7T7J2pQLaRVm4prg@mail.gmail.com> (raw)
In-Reply-To: <20160816005032.28881-1-ab@fmap.me>

[-- Attachment #1: Type: text/plain, Size: 3197 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4354 bytes --]

<div dir="ltr">Hi Nikolay,<div><br></div><div>I&#39;m very sorry to miss these patches and not give an answer soon... </div><div>I totally forgot about them. I&#39;ll take a look this week.</div><div><br></div><div>Lucas De Marchi</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 15, 2016 at 9:50 PM, Nikolay Amiantov <span dir="ltr">&lt;<a href="mailto:ab@fmap.me" target="_blank">ab@fmap.me</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">These series of patches add more control over how kernel modules directory is<br>
found:<br>
<br>
* Add an environment variable which allows to override kernel modules<br>
  directory;<br>
* Allow to hardcode several paths which are searched in order for `uname -r`<br>
  subdirectory;<br>
* Add a configure option to set those paths, instead of hardcoding<br>
  /lib/modules.<br>
<br>
We have used the first patch in NixOS[1] for a long time to point kmod to<br>
kernel modules. While an environment variable is handy and has been solving our<br>
problems, it doesn&#39;t cover all our cases. We have two directories:<br>
<br>
* /run/current-system/kernel-<wbr>modules/lib/modules<br>
* /run/booted-system/kernel-<wbr>modules/lib/modules<br>
<br>
, which are symlinked to modules for current system configuration (i.e. after<br>
an update) and the one which the system was booted with. It allows us to both<br>
give users ability to install new modules and have their old kernel modules<br>
accessible until a reboot (which is useful in case of kernel upgrade).<br>
<br>
Before those patches the necessary logic (see if kernel modules for current<br>
kernel version are available in current-system, if not then fall back to<br>
booted-system) was implemented as a shell wrapper around kmod, which was<br>
unwieldy and didn&#39;t work for applications that use kmod directly. It was<br>
considered better to move this logic to kmod itself. Also, NixOS uses nixpkgs,<br>
a set of distribution-agnostic packages (which run on e.g. Ubuntu and even Mac<br>
OS X where applicable), so it was necessary to preserve /lib/modules as a<br>
fallback directory in kmod for it to work on FHS distributions.<br>
<br>
As a result a set of generic patches was written that implement necessary<br>
behaviour while being potentially useful for upstream. Environment variable is<br>
still used in several places (e.g. in automatic generation and running of<br>
virtual machines) and is useful for us even with the rest of those patches.<br>
<br>
A home of those patches can be found on GitHub[2] along with some<br>
discussion, as can be related NixOS patches and discussion[3].<br>
<br>
Big thanks to Shea Levy for the original patch, extensive code review and<br>
useful advices.<br>
<br>
Additionally, while working on those it was discovered that kmod makes use of<br>
PATH_MAX. This constant is considered harmful[4] because it doesn&#39;t correspond<br>
to real possible length of filesystem paths. This can be considered a bug, but<br>
in those patches it was decided to follow upstream design decisions wherever<br>
possible and so we also use it here.<br>
<br>
[1]: <a href="http://nixos.org/" rel="noreferrer" target="_blank">http://nixos.org/</a><br>
[2]: <a href="https://github.com/abbradar/kmod/" rel="noreferrer" target="_blank">https://github.com/abbradar/<wbr>kmod/</a><br>
[3]: <a href="https://github.com/NixOS/nixpkgs/pull/17738/" rel="noreferrer" target="_blank">https://github.com/NixOS/<wbr>nixpkgs/pull/17738/</a><br>
[4]: <a href="http://insanecoding.blogspot.ru/2007/11/pathmax-simply-isnt.html" rel="noreferrer" target="_blank">http://insanecoding.blogspot.<wbr>ru/2007/11/pathmax-simply-<wbr>isnt.html</a><br>
<br>
--<br>
To unsubscribe from this list: send the line &quot;unsubscribe linux-modules&quot; in<br>
the body of a message to <a href="mailto:majordomo@vger.kernel.org">majordomo@vger.kernel.org</a><br>
More majordomo info at  <a href="http://vger.kernel.org/majordomo-info.html" rel="noreferrer" target="_blank">http://vger.kernel.org/<wbr>majordomo-info.html</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Lucas De Marchi</div>
</div></div>

  parent reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-16  0:50 Nikolay Amiantov
2016-08-16  0:50 ` [PATCH 1/4] libkmod: add MODULE_DIR to override " Nikolay Amiantov
2016-08-16  0:50 ` [PATCH 2/4] libkmod: allow hardcoding array of dirname prefixes Nikolay Amiantov
2016-08-16  0:50 ` [PATCH 3/4] static-nodes: use kmod to get modules directory Nikolay Amiantov
2016-08-16  0:50 ` [PATCH 4/4] libkmod: add --with-modulesdirs configure option Nikolay Amiantov
2016-11-11  2:13 ` Lucas De Marchi [this message]
2016-12-05  3:24 ` Improvements in search of kernel modules directory Lucas De Marchi
2016-12-05 12:35   ` Shea Levy
2016-12-07  7:06     ` Yauheni Kaliuta

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKi4VAL4907RvRJFkUiyVEK3Qjd8EqvBus7T7J2pQLaRVm4prg@mail.gmail.com \
    --to=lucas.de.marchi@gmail.com \
    --cc=ab@fmap.me \
    --cc=linux-modules@vger.kernel.org \
    --cc=shea@shealevy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Modules Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-modules/0 linux-modules/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-modules linux-modules/ https://lore.kernel.org/linux-modules \
		linux-modules@vger.kernel.org linux-modules@archiver.kernel.org
	public-inbox-index linux-modules


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-modules


AGPL code for this site: git clone https://public-inbox.org/ public-inbox