[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230911195048.GK8826@kitsune.suse.cz>
Date: Mon, 11 Sep 2023 21:50:48 +0200
From: Michal Suchánek <msuchanek@...e.de>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: 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>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nicolas Schier <nicolas@...sle.eu>,
linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: 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 <msuchanek@...e.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
Powered by blists - more mailing lists