[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240821175843.GA2531464@thelio-3990X>
Date: Wed, 21 Aug 2024 10:58:43 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Lucas De Marchi <lucas.demarchi@...el.com>,
Michal Suchanek <msuchanek@...e.de>, 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>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nicolas Schier <nicolas@...sle.eu>, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] kmod /usr support
On Tue, Dec 19, 2023 at 05:37:31PM +0900, Masahiro Yamada wrote:
> On Thu, Dec 7, 2023 at 3:37 AM Lucas De Marchi <lucas.demarchi@...el.com> wrote:
> >
> > On Fri, Nov 10, 2023 at 01:13:53PM +0100, Michal Suchanek wrote:
> > >Hello,
> > >
> > >This is resend of the last patch in the series that adds prefix support
> > >to kernel module location together with additional patch for validating
> > >the user supplied input to options that are interpreted as directories.
> > >
> > >Thanks
> >
> > applied, thanks
> >
> > Lucas De Marchi
>
>
>
> If I understood this correctly, MODULE_DIRECTORY is determined
> by "configure --with-module-directory=...", and there is no
> way to change it after that.
>
>
> If so, how to work with cross-building?
>
> Cross-building is typical when building embedded Linux systems.
>
>
> Consider this scenario:
>
> - Your build machine adopts
> MODULE_DIRECTORY=/usr/lib/modules
> - The target embedded system adopts
> MODULE_DIRECTORY=/lib/modules
>
> (or vice a versa)
>
>
>
>
> depmod is used also for cross-building because
> it is executed as a part of "make module_install".
>
>
> The counterpart patch set for Kbuild provides
> KERNEL_MODULE_DIRECTORY, which only changes
> the destination directory to which *.ko are copied.
>
> You cannot change the directory where the
> depmod searches for modules, as it is fixed
> at the compile-time of kmod.
>
>
>
>
> In this case, what we can do is to build another
> instance of kmod configured for the target system,
> and use it for modules_install:
>
> 1. In the kmod source directory
> ./configure --with=module-directory=/lib/modules
> make
>
> 2. make modules_install INSTALL_MOD_PATH=<staging-dir>
> KERNEL_MODULE_DIRECTORY=/lib/modules
> DEPMOD=<new-depmod-you-has-just-built>
>
>
>
> If you use OpenEmbedded etc., this is what you do
> because host tools are built from sources.
>
> But, should it be required all the time?
> Even when the target embedded system uses
> busybox-based modprobe instead of kmod?
>
>
>
> depmod provides --basedir option, which changes
> the prefix part, but there is no way to override
> the stem part, MODULE_DIRECTRY.
>
> In the review of the counter patch set,
> I am suggesting an option to override MODULE_DIRECTRY
> (let's say --moduledir) at least for depmod.
>
> (Perhaps modinfo too, as it also supports --basedir)
>
>
>
> Then, we can change scripts/depmod.sh so that
> Kbuild can propagate KERNEL_MODULE_DIRECTORY
> to depmod.
>
>
> if <depmod supports --moduledir>; then
> set -- "$@" --moduledir "${KERNEL_MODULE_DIRECTORY}"
> fi
>
>
>
> Does it make sense?
Did this conversation go anywhere? After the upgrade to kmod 33 in Arch
Linux, which includes building with the configuration option
'--with-module-directory' set to '/usr/lib/modules' [1], building a
tarzst-pkg breaks for me, seemingly for the reason noted above.
$ make -skj"$(nproc)" ARCH=x86_64 CROSS_COMPILE=x86_64-linux- O=$HOME/tmp/build/linux defconfig tarzst-pkg
depmod: ERROR: could not open directory /home/nathan/tmp/build/linux/tar-install/usr/lib/modules/6.11.0-rc4-00019-gb311c1b497e5: No such file or directory
depmod: FATAL: could not search modules: No such file or directory
$ ls $HOME/tmp/build/linux/tar-install
boot lib
I don't see how to get around this without an option to override
MODULE_DIRECTORY.
I guess I'll ask Arch Linux to revert this option for the time being, as
it mentions they do not really need it at the moment.
[1]: https://gitlab.archlinux.org/archlinux/packaging/packages/kmod/-/commit/0efd732cb78bc0b7851a8367f4dc8e6933f5b99d
Cheers,
Nathan
Powered by blists - more mailing lists