Re: [PATCH v3] depmod: Handle installing modules under a prefix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxx>
> ---
> 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.)

> +
> +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?

Kind regards,
Nicolas


[1]: https://lore.kernel.org/linux-kbuild/1307631448-29848-5-git-send-email-mmarek@xxxxxxx/

>  rm -rf "$tmp_dir"
>  if $depmod_hack_needed; then
> -	symlink="$INSTALL_MOD_PATH/lib/modules/99.98.$KERNELRELEASE"
> +	symlink="$INSTALL_MOD_PATH$KERNEL_MODULE_PREFIX/lib/modules/99.98.$KERNELRELEASE"
>  	ln -s "$KERNELRELEASE" "$symlink"
>  	KERNELRELEASE=99.98.$KERNELRELEASE
>  fi
> -- 
> 2.41.0

-- 
epost|xmpp: nicolas@xxxxxxxxx          irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
     -- frykten for herren er opphav til kunnskap --

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux