linux-modules.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shea Levy <shea@shealevy.com>
To: Lucas De Marchi <lucas.de.marchi@gmail.com>,
	Nikolay Amiantov <ab@fmap.me>
Cc: linux-modules <linux-modules@vger.kernel.org>
Subject: Re: Improvements in search of kernel modules directory
Date: Mon, 05 Dec 2016 07:35:51 -0500	[thread overview]
Message-ID: <8737i25za0.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <CAKi4VA+3z3dqN89yazY2UJ40KmTAHzgW0UfiGfY3odbngqmj7A@mail.gmail.com>

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

Hi Lucas,

Lucas De Marchi <lucas.de.marchi@gmail.com> 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.

Thanks,
Shea

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

  reply	other threads:[~2016-12-05 12:35 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 [this message]
2016-12-07  7:06     ` Yauheni Kaliuta

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:
  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=8737i25za0.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me \
    --to=shea@shealevy.com \
    --cc=ab@fmap.me \
    --cc=linux-modules@vger.kernel.org \
    --cc=lucas.de.marchi@gmail.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
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).