On Tue, Dec 12, 2023 at 10:03 PM Michal Suchánek <msuchanek@xxxxxxx> wrote:
>
> On Mon, Dec 11, 2023 at 01:29:15PM +0900, Masahiro Yamada wrote:
> > On Mon, Dec 11, 2023 at 6:07 AM Michal Suchánek <msuchanek@xxxxxxx> wrote:
> > >
> > > Hello!
> > >
> > > On Mon, Dec 11, 2023 at 03:43:44AM +0900, Masahiro Yamada wrote:
> > > > On Thu, Dec 7, 2023 at 4:48 AM Michal Suchanek <msuchanek@xxxxxxx> wrote:
> > > > >
> > > > > Some distributions aim at shipping all files in /usr.
> > > > >
> > > > > The path under which kernel modules are installed is hardcoded to /lib
> > > > > which conflicts with this goal.
> > > > >
> > > > > When kmod provides kmod.pc, use it to determine the correct module
> > > > > installation path.
> > > > >
> > > > > With kmod that does not provide the config /lib/modules is used as
> > > > > before.
> > > > >
> > > > > While pkg-config does not return an error when a variable does not exist
> > > > > the kmod configure script puts some effort into ensuring that
> > > > > module_directory is non-empty. With that empty module_directory from
> > > > > pkg-config can be used to detect absence of the variable.
> > > > >
> > > > > Signed-off-by: Michal Suchanek <msuchanek@xxxxxxx>
> > > > > ---
> > > > > v6:
> > > > > - use ?= instead of := to make it easier to override the value
> > > >
> > > >
> > > > "KERNEL_MODULE_DIRECTORY=/local/usr/lib/modules make modules_install"
> > > > will override the install destination, but
> > > > depmod will not be not aware of it.
> > >
> > > At the same time if you know what you are doing you can build a src rpm
> > > for another system that uses a different location.
> > >
> > > > How to avoid the depmod error?
> > >
> > > Not override the variable?
> >
> > You are not answering my question.
> > You intentionally changed := to ?=.
> >
> > This implies that KERNEL_MODULE_DIRECTORY is an interface to users,
> > and should be documented in Documentation/kbuild/kbuild.rst
>
> That's reasonable
>
> > However, it never works if it is overridden from the env variable
> > or make command line because there is no way to let depmod know
> > the fact that KERNEL_MODULE_DIRECTORY has been overridden.
>
> And there should not. kmod is not aware, kbuild is. That's the
> direction of information flow. kmod defines where it looks for the
> modules, and kbuild shoukld install the modules there.
Then, you cannot explain why KERNEL_MODULE_DIRECTORY should be exposed
as a user interface.
The MODULE_DIRECTORY in depmod is determined when kmod is compiled.
Kbuild takes KERNEL_MODULE_DIRECTORY from pkg-config.
If these two do not agree, it never works.
> If the user knows better (eg. possibility of building src-rpm for a
> different you brought up) they can override the autodetection.
No, it does not work.
The user has no way to override the MODULE_DIRECTORY in depmod.
> > In my understanding, depmod does not provide an option to
> > specify the module directory from a command line option, does it?
>
> No it does not.
>
> > If not, is it reasonable to add a new option to depmod?
>
> I don't think so. The module directory is intentionally in a fixed
> location. It can be set at compile time, and that's it.
>
> Then when running depmod on the target distribution either kbuild and
> kmod agree on the location or the build fails. That's the intended
> outcome.
>
> kmod recently grew the ability to use modules outside of module
> directory. For that to work internally the path to these out-of-kernel
> modules is stored as absolute path, and the path of modules that are in
> the module directory is stored relative to the module directory.
>
> Setting the module directory location dynamically still should not break
> this but I am not sure it's a great idea. In the end modprobe needs to
> find those modules, and if depmod puts the modules.dep in arbitrary
> location it will not.
That is true when modules are compiled and installed on the local machine.
If you create an SRPM with KERNEL_MODULE_DIRECTORY,
builders must follow it.
>
> > depmod provides the "-b basedir" option, but it only allows
> > adding a prefix to the default "/lib/modules/<version>".
>
> Yes, that's for installation into a staging directory, and there again
> the modules that are inside the module directory are considedred
> 'in-kernel'. Not sure how well this even works with 'out-of-kernel'
> modules.
>
> > (My original idea to provide the prefix_part, it would have worked
> > like -b "${INSTALL_MOD_PATH}${MOD_PREFIX}", which you refused)
>
> It's not clear that adding a prefix covers all use cases. It is an
> arbitrary limitation that the module path must end with '/lib/modules'.
>
> It may allow taking some shortcuts in some places but is unnecessarily
> limiting.
>
> Thanks
>
> Michal
--
Best Regards
Masahiro Yamada
