Message ID | cover.1689681454.git.msuchanek@suse.de (mailing list archive) |
---|---|
Headers | show |
Series | kmod /usr support | expand |
Hello, On Tue, Jul 18, 2023 at 02:01:51PM +0200, Michal Suchanek wrote: > Hello, > > with these patches it is possible to install kernel modules in an arbitrary > directory - eg. moving the /lib/modules to /usr/lib/modules or /opt/linux. > > While the modprobe.d and depmod.d search which already includes multiple > paths is expanded to also include $(prefix) the module directory still > supports only one location, only a different one under $(module_directory). > > Having kmod search multiple module locations while only one is supported now > might break some assumption about relative module path corresponding to a > specific file, would require more invasive changes to implement, and is not > supportive of the goal of moving the modules away from /lib. > > Both kmod and the kernel need to be patched to make use of this feature. > Patched kernel is backwards compatible with older kmod. Patched kmod > with $(module_directory) set to /lib/modules is equivalent to unpatched kmod. The patch to kernel to support autodetection of module directory is rejected. However, a workaround like make MODLIB='$(INSTALL_MOD_PATH)/usr/lib/modules/$(KERNELRELEASE)' is suggested. Can you consider inluding the kmod changes? Thanks Michal > > Thanks > > Michal > > Link: https://lore.kernel.org/linux-modules/20210112160211.5614-1-msuchanek@suse.de/ > > v4: set whole path to module directory instead of adding prefix > v5: use pkg-config instead of jq, fix build on openssl without sm3 support > > > Michal Suchanek (5): > configure: Detect openssl sm3 support > man/depmod.d: Fix incorrect /usr/lib search path > libkmod, depmod: Load modprobe.d, depmod.d from ${prefix}/lib. > kmod: Add pkgconfig file with kmod compile time configuration > libkmod, depmod, modprobe: Make directory for kernel modules > configurable > > Makefile.am | 6 +- > configure.ac | 30 ++++++++ > libkmod/libkmod.c | 11 +-- > man/Makefile.am | 10 ++- > man/depmod.d.xml | 9 ++- > man/depmod.xml | 4 +- > man/modinfo.xml | 2 +- > man/modprobe.d.xml | 1 + > 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 | 7 +- > tools/kmod.pc.in | 10 +++ > tools/modinfo.c | 4 +- > tools/modprobe.c | 4 +- > tools/static-nodes.c | 6 +- > 19 files changed, 156 insertions(+), 91 deletions(-) > create mode 100644 tools/kmod.pc.in > > -- > 2.41.0 >
On Fri, Aug 18, 2023 at 12:15 PM Michal Suchánek <msuchanek@suse.de> wrote: > > Hello, > > On Tue, Jul 18, 2023 at 02:01:51PM +0200, Michal Suchanek wrote: > > Hello, > > > > with these patches it is possible to install kernel modules in an arbitrary > > directory - eg. moving the /lib/modules to /usr/lib/modules or /opt/linux. > > > > While the modprobe.d and depmod.d search which already includes multiple > > paths is expanded to also include $(prefix) the module directory still > > supports only one location, only a different one under $(module_directory). > > > > Having kmod search multiple module locations while only one is supported now > > might break some assumption about relative module path corresponding to a > > specific file, would require more invasive changes to implement, and is not > > supportive of the goal of moving the modules away from /lib. > > > > Both kmod and the kernel need to be patched to make use of this feature. > > Patched kernel is backwards compatible with older kmod. Patched kmod > > with $(module_directory) set to /lib/modules is equivalent to unpatched kmod. > > The patch to kernel to support autodetection of module directory is > rejected. However, a workaround like > > make MODLIB='$(INSTALL_MOD_PATH)/usr/lib/modules/$(KERNELRELEASE)' > > is suggested. > > Can you consider inluding the kmod changes? Hi. I have a question about your original patch for the Kbuild change. In your patch, Kbuild runs 'kmod config' or 'pkg-config --variable=module_directory kmod', then sets the returned string to MODLIB. If kmod is configured to use /usr/lib/modules, /opt/modules, or whatever, should we change the installation path of the debug vdso accordingly? Currently, the debug vdso is always installed to /lib/modules/$(KERNELRELEASE)/vdso/. However, modules and vdso are unrelated to each other. kmod does not care about vdso. The following commits started to install debug vdso. Commit 8150caad0226 ("[POWERPC] powerpc vDSO: install unstripped copies on disk") Commit f79eb83b3af4 ("x86: Install unstripped copy of 64bit vdso to disk") I do not know why they chose $(MODLIB)/vdso as the install destination. I am thinking of split the variable into two: MODLIB - installation path for modules VDSOLIB - installation path for debug vdso (not affected by kmod config) I think that is the way to do this correctly. > > Thanks > > Michal > > > > > Thanks > > > > Michal > > > > Link: https://lore.kernel.org/linux-modules/20210112160211.5614-1-msuchanek@suse.de/ > > > > v4: set whole path to module directory instead of adding prefix > > v5: use pkg-config instead of jq, fix build on openssl without sm3 support > > > > > > Michal Suchanek (5): > > configure: Detect openssl sm3 support > > man/depmod.d: Fix incorrect /usr/lib search path > > libkmod, depmod: Load modprobe.d, depmod.d from ${prefix}/lib. > > kmod: Add pkgconfig file with kmod compile time configuration > > libkmod, depmod, modprobe: Make directory for kernel modules > > configurable > > > > Makefile.am | 6 +- > > configure.ac | 30 ++++++++ > > libkmod/libkmod.c | 11 +-- > > man/Makefile.am | 10 ++- > > man/depmod.d.xml | 9 ++- > > man/depmod.xml | 4 +- > > man/modinfo.xml | 2 +- > > man/modprobe.d.xml | 1 + > > 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 | 7 +- > > tools/kmod.pc.in | 10 +++ > > tools/modinfo.c | 4 +- > > tools/modprobe.c | 4 +- > > tools/static-nodes.c | 6 +- > > 19 files changed, 156 insertions(+), 91 deletions(-) > > create mode 100644 tools/kmod.pc.in > > > > -- > > 2.41.0 > > -- Best Regards Masahiro Yamada
On Sat, Aug 19, 2023 at 08:25:52PM +0900, Masahiro Yamada wrote: > On Fri, Aug 18, 2023 at 12:15 PM Michal Suchánek <msuchanek@suse.de> wrote: > > > > Hello, > > > > On Tue, Jul 18, 2023 at 02:01:51PM +0200, Michal Suchanek wrote: > > > Hello, > > > > > > with these patches it is possible to install kernel modules in an arbitrary > > > directory - eg. moving the /lib/modules to /usr/lib/modules or /opt/linux. > > > > > > While the modprobe.d and depmod.d search which already includes multiple > > > paths is expanded to also include $(prefix) the module directory still > > > supports only one location, only a different one under $(module_directory). > > > > > > Having kmod search multiple module locations while only one is supported now > > > might break some assumption about relative module path corresponding to a > > > specific file, would require more invasive changes to implement, and is not > > > supportive of the goal of moving the modules away from /lib. > > > > > > Both kmod and the kernel need to be patched to make use of this feature. > > > Patched kernel is backwards compatible with older kmod. Patched kmod > > > with $(module_directory) set to /lib/modules is equivalent to unpatched kmod. > > > > The patch to kernel to support autodetection of module directory is > > rejected. However, a workaround like > > > > make MODLIB='$(INSTALL_MOD_PATH)/usr/lib/modules/$(KERNELRELEASE)' > > > > is suggested. > > > > Can you consider inluding the kmod changes? > > > Hi. > > I have a question about your original patch > for the Kbuild change. > > In your patch, Kbuild runs 'kmod config' or > 'pkg-config --variable=module_directory kmod', > then sets the returned string to MODLIB. > > > If kmod is configured to use /usr/lib/modules, > /opt/modules, or whatever, > should we change the installation path of the debug > vdso accordingly? > > Currently, the debug vdso is always installed > to /lib/modules/$(KERNELRELEASE)/vdso/. > > However, modules and vdso are unrelated to each other. > kmod does not care about vdso. > > > The following commits started to install debug vdso. > > Commit 8150caad0226 ("[POWERPC] powerpc vDSO: install unstripped > copies on disk") > Commit f79eb83b3af4 ("x86: Install unstripped copy of 64bit vdso to disk") > > > I do not know why they chose $(MODLIB)/vdso as the install destination. It's the only directory that exists per-kernel-release. While technically vdso has nothing to do with modules there is no other place where it can be stored where it would not conflict between kernel releases so far. In fact the distro followed the pattern and started dumping other things not related to kernel modules into $(MODLIB) for this very reason. Also from the distribution point of view $(MODLIB) is listed as owned by the kernel package, and additional files that might be there sometimes need not be specially handled. Finally any tools that can find vdso today will search for it in $(MODLIB), and consequently moving it elsewhere is not practical. If the makefiles grow a VDSOLIB it should default to MODLIB. It may be useful for somebody to have this flexibility in the future but I am not interested for my use case. Thanks Michal
On Sat, Aug 19, 2023 at 08:25:52PM +0900, Masahiro Yamada wrote: > On Fri, Aug 18, 2023 at 12:15 PM Michal Suchánek <msuchanek@suse.de> wrote: > > > > Hello, > > > > On Tue, Jul 18, 2023 at 02:01:51PM +0200, Michal Suchanek wrote: > > > Hello, > > > > > > with these patches it is possible to install kernel modules in an arbitrary > > > directory - eg. moving the /lib/modules to /usr/lib/modules or /opt/linux. > > > > > > While the modprobe.d and depmod.d search which already includes multiple > > > paths is expanded to also include $(prefix) the module directory still > > > supports only one location, only a different one under $(module_directory). > > > > > > Having kmod search multiple module locations while only one is supported now > > > might break some assumption about relative module path corresponding to a > > > specific file, would require more invasive changes to implement, and is not > > > supportive of the goal of moving the modules away from /lib. > > > > > > Both kmod and the kernel need to be patched to make use of this feature. > > > Patched kernel is backwards compatible with older kmod. Patched kmod > > > with $(module_directory) set to /lib/modules is equivalent to unpatched kmod. > > > > The patch to kernel to support autodetection of module directory is > > rejected. However, a workaround like > > > > make MODLIB='$(INSTALL_MOD_PATH)/usr/lib/modules/$(KERNELRELEASE)' > > > > is suggested. > > > > Can you consider inluding the kmod changes? > > > Hi. > > I have a question about your original patch > for the Kbuild change. > > In your patch, Kbuild runs 'kmod config' or > 'pkg-config --variable=module_directory kmod', > then sets the returned string to MODLIB. > > > If kmod is configured to use /usr/lib/modules, > /opt/modules, or whatever, > should we change the installation path of the debug > vdso accordingly? > > Currently, the debug vdso is always installed > to /lib/modules/$(KERNELRELEASE)/vdso/. > > However, modules and vdso are unrelated to each other. > kmod does not care about vdso. > > > The following commits started to install debug vdso. > > Commit 8150caad0226 ("[POWERPC] powerpc vDSO: install unstripped > copies on disk") > Commit f79eb83b3af4 ("x86: Install unstripped copy of 64bit vdso to disk") > > > I do not know why they chose $(MODLIB)/vdso as the install destination. > > > I am thinking of split the variable into two: > MODLIB - installation path for modules > VDSOLIB - installation path for debug vdso (not affected by kmod config) > > I think that is the way to do this correctly. The source and build symlinks that point at the kernel tree are not modules either yet they are in the module directory as well. Thanks Michal
Hello, it has been a few months since these kmod patches have been posted, and a new kmod versio has been released since. Is there any interest in adding this to kmod? Thanks Michal On Tue, Jul 18, 2023 at 02:01:51PM +0200, Michal Suchanek wrote: > Hello, > > with these patches it is possible to install kernel modules in an arbitrary > directory - eg. moving the /lib/modules to /usr/lib/modules or /opt/linux. > > While the modprobe.d and depmod.d search which already includes multiple > paths is expanded to also include $(prefix) the module directory still > supports only one location, only a different one under $(module_directory). > > Having kmod search multiple module locations while only one is supported now > might break some assumption about relative module path corresponding to a > specific file, would require more invasive changes to implement, and is not > supportive of the goal of moving the modules away from /lib. > > Both kmod and the kernel need to be patched to make use of this feature. > Patched kernel is backwards compatible with older kmod. Patched kmod > with $(module_directory) set to /lib/modules is equivalent to unpatched kmod. > > Thanks > > Michal > > Link: https://lore.kernel.org/linux-modules/20210112160211.5614-1-msuchanek@suse.de/ > > v4: set whole path to module directory instead of adding prefix > v5: use pkg-config instead of jq, fix build on openssl without sm3 support > > > Michal Suchanek (5): > configure: Detect openssl sm3 support > man/depmod.d: Fix incorrect /usr/lib search path > libkmod, depmod: Load modprobe.d, depmod.d from ${prefix}/lib. > kmod: Add pkgconfig file with kmod compile time configuration > libkmod, depmod, modprobe: Make directory for kernel modules > configurable > > Makefile.am | 6 +- > configure.ac | 30 ++++++++ > libkmod/libkmod.c | 11 +-- > man/Makefile.am | 10 ++- > man/depmod.d.xml | 9 ++- > man/depmod.xml | 4 +- > man/modinfo.xml | 2 +- > man/modprobe.d.xml | 1 + > 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 | 7 +- > tools/kmod.pc.in | 10 +++ > tools/modinfo.c | 4 +- > tools/modprobe.c | 4 +- > tools/static-nodes.c | 6 +- > 19 files changed, 156 insertions(+), 91 deletions(-) > create mode 100644 tools/kmod.pc.in > > -- > 2.41.0 >
On Tue, Oct 17, 2023 at 05:45:39PM +0200, Michal Suchánek wrote: >Hello, > >it has been a few months since these kmod patches have been posted, and >a new kmod versio has been released since. > >Is there any interest in adding this to kmod? yes, but I think the main drag is deciding with the kernel build system maintainers what they are willing to accept as an interface. There isn't much point in exporting a json config if from the kernel side they would rather use something else. Or to use pkg-config. I confess I lost track of that discussion. Did that settle with pkg-config being the preferred solution? Lucas De Marchi
On Tue, Oct 17, 2023 at 11:18:23AM -0500, Lucas De Marchi wrote: > On Tue, Oct 17, 2023 at 05:45:39PM +0200, Michal Suchánek wrote: > > Hello, > > > > it has been a few months since these kmod patches have been posted, and > > a new kmod versio has been released since. > > > > Is there any interest in adding this to kmod? > > yes, but I think the main drag is deciding with the kernel build system > maintainers what they are willing to accept as an interface. There isn't > much point in exporting a json config if from the kernel side they would > rather use something else. Or to use pkg-config. > > I confess I lost track of that discussion. Did that settle with > pkg-config being the preferred solution? The current discussion about the kernel side can be found here: https://lore.kernel.org/linux-kbuild/20231017151050.GJ6241@kitsune.suse.cz/T/#t My impression is that pkg-config is accepted as an interface on the basis that it's already required for building the kernel while jq is currently required only for some additional optional tools. Thanks Michal