[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZLFhuf95srX2wvJc@fjasle.eu>
Date: Fri, 14 Jul 2023 16:54:49 +0200
From: Nicolas Schier <nicolas@...sle.eu>
To: Michal Such�nek <msuchanek@...e.de>
Cc: linux-modules@...r.kernel.org, Takashi Iwai <tiwai@...e.com>,
Lucas De Marchi <lucas.de.marchi@...il.com>,
Michal Koutn� <mkoutny@...e.com>,
Jiri Slaby <jslaby@...e.com>, Jan Engelhardt <jengelh@...i.de>,
Masahiro Yamada <masahiroy@...nel.org>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] depmod: Handle installing modules under a prefix
On Fri, Jul 14, 2023 at 04:30:02PM +0200, Michal Such�nek wrote:
> Hello,
>
> On Fri, Jul 14, 2023 at 04:05:10PM +0200, Nicolas Schier wrote:
> > On Fri, Jul 14, 2023 at 02:21:08PM +0200 Michal Suchanek wrote:
> > > Some distributions aim at not shipping any files in / outside of usr.
> >
> > For me, preventing negation often makes things easier, e.g.: "... aim at
> > shipping files only below /usr".
> >
> > >
> > > The path under which kernel modules are installed is hardcoded to /lib
> > > which conflicts with this goal.
> > >
> > > When kmod provides the config command, use it to determine the correct
> > > module installation prefix.
> > >
> > > This is a prefix under which the modules are searched by kmod on the
> > > system, and is separate from the temporary staging location already
> > > supported by INSTALL_MOD_PATH.
> > >
> > > With kmod that does not provide the config command empty prefix is used
> > > as before.
> > >
> > > Signed-off-by: Michal Suchanek <msuchanek@...e.de>
> > > ---
> > > v2: Avoid error on systems with kmod that does not support config
> > > command
> > > v3: More verbose commit message
> > > ---
> > > Makefile | 4 +++-
> > > scripts/depmod.sh | 8 ++++----
> > > 2 files changed, 7 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index 47690c28456a..b1fea135bdec 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -1165,7 +1165,9 @@ export INSTALL_DTBS_PATH ?= $(INSTALL_PATH)/dtbs/$(KERNELRELEASE)
> > > # makefile but the argument can be passed to make if needed.
> > > #
> > >
> > > -MODLIB = $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
> > > +export KERNEL_MODULE_PREFIX := $(shell kmod config &> /dev/null && kmod config | jq -r .module_prefix)
> >
> > All other calls of `jq` that I could find are located at tools/; as this here
> > is evaluated on each invocation, this should probably be documented in
> > Documentation/process/changes.rst?
> >
> > (Absence of `jq` will cause error messages, even with CONFIG_MODULES=n.)
>
> That's a good point.
>
> >
> > > +
> > > +MODLIB = $(INSTALL_MOD_PATH)$(KERNEL_MODULE_PREFIX)/lib/modules/$(KERNELRELEASE)
> > > export MODLIB
> > >
> > > PHONY += prepare0
> > > diff --git a/scripts/depmod.sh b/scripts/depmod.sh
> > > index 3643b4f896ed..88ac79056153 100755
> > > --- a/scripts/depmod.sh
> > > +++ b/scripts/depmod.sh
> > > @@ -27,16 +27,16 @@ fi
> > > # numbers, so we cheat with a symlink here
> > > depmod_hack_needed=true
> > > tmp_dir=$(mktemp -d ${TMPDIR:-/tmp}/depmod.XXXXXX)
> > > -mkdir -p "$tmp_dir/lib/modules/$KERNELRELEASE"
> > > +mkdir -p "$tmp_dir$KERNEL_MODULE_PREFIX/lib/modules/$KERNELRELEASE"
> > > if "$DEPMOD" -b "$tmp_dir" $KERNELRELEASE 2>/dev/null; then
> > > - if test -e "$tmp_dir/lib/modules/$KERNELRELEASE/modules.dep" -o \
> > > - -e "$tmp_dir/lib/modules/$KERNELRELEASE/modules.dep.bin"; then
> > > + if test -e "$tmp_dir$KERNEL_MODULE_PREFIX/lib/modules/$KERNELRELEASE/modules.dep" -o \
> > > + -e "$tmp_dir$KERNEL_MODULE_PREFIX/lib/modules/$KERNELRELEASE/modules.dep.bin"; then
> > > depmod_hack_needed=false
> > > fi
> > > fi
> >
> > I'd like to come back to the statement from Masahiro: Is the check above,
> > against some very old versions of depmod [1], the only reason for this patch?
> >
> > If we could remove that, would
> >
> > make INSTALL_MOD_PATH="$(kmod config | jq -r .module_prefix)" modules_install
> >
> > be sufficient?
>
> No, the INSTALL_MOD_PATH is passed as the -b argument to depmod while
> the newly added part is not because it's integral part of where the
> modules are installed on the system, and not the staging area path.
Ah, thanks. So just for my understanding, could this be a (non-gentle)
alternative version of your patch, w/o modifying top-level Makefile?
diff --git a/scripts/depmod.sh b/scripts/depmod.sh
index 3643b4f896ed..72c819de0669 100755
--- a/scripts/depmod.sh
+++ b/scripts/depmod.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
# SPDX-License-Identifier: GPL-2.0
#
# A depmod wrapper used by the toplevel Makefile
@@ -23,6 +23,8 @@ if [ -z $(command -v $DEPMOD) ]; then
exit 0
fi
+kmod_version=$(( $(kmod --version | sed -rne 's/^kmod version ([0-9]+).*$/\1/p') ))
+
# older versions of depmod require the version string to start with three
# numbers, so we cheat with a symlink here
depmod_hack_needed=true
@@ -35,6 +37,13 @@ if "$DEPMOD" -b "$tmp_dir" $KERNELRELEASE 2>/dev/null; then
fi
fi
rm -rf "$tmp_dir"
+
+if [ "${kmod_version}" -gt 32 ]; then
+ kmod_prefix="$(kmod config | jq -r .module_prefix)"
+ INSTALL_MOD_PATH="${INSTALL_MOD_PATH#${kmod_prefix}"
+ depmod_hack_needed=false
+fi
+
if $depmod_hack_needed; then
symlink="$INSTALL_MOD_PATH/lib/modules/99.98.$KERNELRELEASE"
ln -s "$KERNELRELEASE" "$symlink"
(untested, and assuming that kmod module prefix is in kmod >= 32)
Or are I am still missing something?
> Was busybox ever fixed to not require the hack?
I haven't checked that, yet.
Kind regards,
Nicolas
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists