All of
 help / color / mirror / Atom feed
From: Yauheni Kaliuta <>
To: Shea Levy <>
Cc: Lucas De Marchi <>,
	Nikolay Amiantov <>,
	linux-modules <>
Subject: Re: Improvements in search of kernel modules directory
Date: Wed, 07 Dec 2016 09:06:35 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <8737i25za0.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> (Shea Levy's message of "Mon, 05 Dec 2016 07:35:51 -0500")

Hi, Shea!

>>>>> On Mon, 05 Dec 2016 07:35:51 -0500, Shea Levy  wrote:
 > Lucas De Marchi <> writes:
 >> An environment variable for the library IMO is not a good option. If
 >> you take a look on how we separate the responsibility of each
 >> component you will see that we parse environment vars on the tools
 >> (e.g. modprobe) not on the library.

 > Can you explain a bit why an environment variable is not OK here? The
 > code path using get_kernel_release is shared by many tools, and as
 > things currently stand there is already a global setting fixed in this
 > file. If we were to move this out to the tools, we would have to
 > duplicate this code in several places and any external tools linked
 > against kmod (e.g. systemd) will need to be updated as well. By default
 > users of this interface will not know that they need to check the env
 > var, because as things stand the code will just work, so it's likely
 > that new uses, in and out of kmod, will start out not respecting
 > MODULE_DIR and only after someone notices things aren't working for a
 > case relying on it will they be changed.

What worries me with the approach is increasing ambiguity and number of
points of syncronization.

I see kernel modules directory location as a part of shared state of
several parties, at least "make modules_install" of kbuild, module builders
like dkms, binary module packages, the kmod tools themself (this is
significant different to variables like LS_COLORS, which affect only the
current program run). Since the possible modules directories are mutually
exclusive (only one is taken in use), they must be somehow in sync, or I
expect some surprises for users, a-la:

- you install a module package, it has it's own idea about the directory
  (most probably hardcoded), but depmod from postinstall script doesn't
  generate working configuration (but doesn't fail as well most probably,
  since it's just working on a different directory);
- in general, result of an operation like "dpkg -i module.deb" depends of
  which user (with what environment) performs it;

Something similar about several directories. If we install some package
which installs modules (and creates the dir) into a directory which did not
exist and is checked earlier, then the old modules stop working without
very obvious (as for me) connection with the installed one.

The modules installation tools should be aware somehow about directory,
which is going to be used.

Since, as I mentioned, they are exclusive, there is no analogy with
variables like PATH, where all of the dirs are part of the configuration.

I'm not sure if the concerns are important in the real life.

Yauheni Kaliuta

      reply	other threads:[~2016-12-07  7:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-16  0:50 Improvements in search of kernel modules directory 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 ` Improvements in search of kernel modules directory Lucas De Marchi
2016-12-05  3:24 ` Lucas De Marchi
2016-12-05 12:35   ` Shea Levy
2016-12-07  7:06     ` Yauheni Kaliuta [this message]

Reply instructions:

You may reply publicly 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:

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

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.