Re: [PATCH kmod v5 0/5] kmod /usr support
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.gj6...@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
Re: [PATCH kmod v5 0/5] kmod /usr support
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
Re: [PATCH kmod v5 0/5] kmod /usr support
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-msucha...@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
>
Re: [PATCH kmod v5 0/5] kmod /usr support
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 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
