| Message ID | cover.1699618135.git.msuchanek@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | kmod /usr support | expand |
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
On Thu, Dec 7, 2023 at 3:37 AM Lucas De Marchi <lucas.demarchi@intel.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?
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@intel.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
On Wed, Aug 21, 2024 at 10:58:43AM GMT, Nathan Chancellor wrote:
>Did this conversation go anywhere? After the upgrade to kmod 33 in Arch
no, it stalled, thanks for reminding me. I will follow up on it.
Lucas De Marchi
On Tue, Dec 19, 2023 at 05:37:31PM GMT, Masahiro Yamada wrote: >On Thu, Dec 7, 2023 at 3:37 AM Lucas De Marchi <lucas.demarchi@intel.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. I was thinking the `pkg-config --variable=module_directory` from the target would be sufficient, but... > > >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, the target system may not even have depmod actually, so using just the host one seems more appropriate. But target should have the kmod.pc for the pkg-config call to work. >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? no, I don't think we can rely on depmod from the target. > > > >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. ok > >(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? yep thanks and sorry for missing this reply Lucas De Marchi > > > > >-- >Best Regards >Masahiro Yamada
Hello, On Thu, Aug 22, 2024 at 01:05:11AM -0500, Lucas De Marchi wrote: > On Tue, Dec 19, 2023 at 05:37:31PM GMT, Masahiro Yamada wrote: > > On Thu, Dec 7, 2023 at 3:37 AM Lucas De Marchi <lucas.demarchi@intel.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. > > I was thinking the `pkg-config --variable=module_directory` > from the target would be sufficient, but... > > > > > > > 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, > > the target system may not even have depmod actually, so using just the > host one seems more appropriate. But target should have the kmod.pc for > the pkg-config call to work. > > > 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? > > no, I don't think we can rely on depmod from the target. > > > > > > > > > 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. > > ok > > > > > (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? It does not make sense for the common case: building kernel for the host system. Then overriding the directory is wrong, and using what kmod was compiled with is needed to get correct module directory layout. Or it would make sense if both was done: Default KERNEL_MODULE_DIRECTORY to what kmod was compiled with, and then pass the actual value to depmod so that depmod uses the compiled-in value by default, and the user-provided value when KERNEL_MODULE_DIRECTORY was overridden by the user. Thanks Michal
On 2024/08/21, Nathan Chancellor wrote: > 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@intel.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 > Since we've officially (?) switched to Github for issues, I opened one [1]. I suspect it would be a little harder to get lost in the noise, although Github and all that. Everyone feel free to subscribe, comment ... or even send some patches. Ideally we'll get Michal to help this although I'm not sure how busy he is. HTH Emil [1] https://github.com/kmod-project/kmod/issues/85
On Thu, Aug 22, 2024 at 5:36 PM Michal Suchánek <msuchanek@suse.de> wrote: > > Hello, > > On Thu, Aug 22, 2024 at 01:05:11AM -0500, Lucas De Marchi wrote: > > On Tue, Dec 19, 2023 at 05:37:31PM GMT, Masahiro Yamada wrote: > > > On Thu, Dec 7, 2023 at 3:37 AM Lucas De Marchi <lucas.demarchi@intel.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. > > > > I was thinking the `pkg-config --variable=module_directory` > > from the target would be sufficient, but... > > > > > > > > > > > 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, > > > > the target system may not even have depmod actually, so using just the > > host one seems more appropriate. But target should have the kmod.pc for > > the pkg-config call to work. > > > > > 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? > > > > no, I don't think we can rely on depmod from the target. > > > > > > > > > > > > > > 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. > > > > ok > > > > > > > > (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? > > It does not make sense for the common case: building kernel for the host > system. > > Then overriding the directory is wrong, and using what kmod was compiled > with is needed to get correct module directory layout. NACK. scripts/Makefile.modinst and depmod must agree about the install destination. Both must refer to the same ${KERNEL_MODULE_DIRECTORY}. > > Or it would make sense if both was done: > > Default KERNEL_MODULE_DIRECTORY to what kmod was compiled with, and > then pass the actual value to depmod so that depmod uses the compiled-in > value by default, and the user-provided value when > KERNEL_MODULE_DIRECTORY was overridden by the user. > > Thanks > > Michal
On Fri, Aug 23, 2024 at 10:03:05PM +0900, Masahiro Yamada wrote: > On Thu, Aug 22, 2024 at 5:36 PM Michal Suchánek <msuchanek@suse.de> wrote: > > > > Hello, > > > > On Thu, Aug 22, 2024 at 01:05:11AM -0500, Lucas De Marchi wrote: > > > On Tue, Dec 19, 2023 at 05:37:31PM GMT, Masahiro Yamada wrote: > > > > On Thu, Dec 7, 2023 at 3:37 AM Lucas De Marchi <lucas.demarchi@intel.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. > > > > > > I was thinking the `pkg-config --variable=module_directory` > > > from the target would be sufficient, but... > > > > > > > > > > > > > > > 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, > > > > > > the target system may not even have depmod actually, so using just the > > > host one seems more appropriate. But target should have the kmod.pc for > > > the pkg-config call to work. > > > > > > > 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? > > > > > > no, I don't think we can rely on depmod from the target. > > > > > > > > > > > > > > > > > > > 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. > > > > > > ok > > > > > > > > > > > (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? > > > > It does not make sense for the common case: building kernel for the host > > system. > > > > Then overriding the directory is wrong, and using what kmod was compiled > > with is needed to get correct module directory layout. > > > NACK. > > scripts/Makefile.modinst and depmod must agree about > the install destination. > > Both must refer to the same ${KERNEL_MODULE_DIRECTORY}. Nack to what, exactly? And what needs to agree here, exactly? If the kmod was compiled with a non-default kernel module directory then for depmod and scripts/Makefile.modinst to agree the kernel makefile should extract the directory it was compile with from kmod kmod, and that is the change that was not merged. Overriding the directory with an option only for the kernel build will make modules_install install the modules in the wrong directory. Of course, the user is free to move them elsewhere afterwards but I would say they should not need to do that. Then there is the possibility that the build is for a different target system, and the host kmod and scripts/Makefile.modinst agreeing is not enough. Then either a 'cross' kmod can be built, and this will again work so long as both path and pkgconfig path point to this modified kmod. Or kmod can grow an option to set the kernel module directory dynamically. However, setting it to the current hardcoded value will again break the case when building for the current system with non-default kernel module directory location. Unless both is done - that is the default is read from kmod, user is provided with an option to override the default, and whatever ends up being used by scripts/Makefile.modinst is then passed back to depmod. Or do you envision some other solution? Thanks Michal > > Or it would make sense if both was done: > > > > Default KERNEL_MODULE_DIRECTORY to what kmod was compiled with, and > > then pass the actual value to depmod so that depmod uses the compiled-in > > value by default, and the user-provided value when > > KERNEL_MODULE_DIRECTORY was overridden by the user. > > > > Thanks > > > > Michal > > > > -- > Best Regards > Masahiro Yamada
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 Michal Michal Suchanek (2): libkmod, depmod, modprobe: Make directory for kernel modules configurable configure: Check that provided paths are absolute Makefile.am | 3 +- configure.ac | 24 ++++++ libkmod/libkmod.c | 4 +- man/Makefile.am | 1 + man/depmod.d.xml | 6 +- man/depmod.xml | 4 +- man/modinfo.xml | 2 +- man/modprobe.xml | 2 +- man/modules.dep.xml | 6 +- testsuite/module-playground/Makefile | 2 +- testsuite/setup-rootfs.sh | 109 +++++++++++++++------------ testsuite/test-depmod.c | 16 ++-- testsuite/test-testsuite.c | 8 +- tools/depmod.c | 6 +- tools/kmod.pc.in | 1 + tools/modinfo.c | 4 +- tools/modprobe.c | 4 +- tools/static-nodes.c | 6 +- 18 files changed, 124 insertions(+), 84 deletions(-)