On 12/12/2024 02:08, Masahiro Yamada wrote:
On Wed, Dec 11, 2024 at 9:21 PM Jon Hunter <jonathanh@xxxxxxxxxx> wrote:
On 11/12/2024 02:39, Masahiro Yamada wrote:
On Wed, Dec 11, 2024 at 12:34 AM Jon Hunter <jonathanh@xxxxxxxxxx> wrote:
Hi Masahiro,
On 10/11/2024 01:34, Masahiro Yamada wrote:
Currently, Kbuild always operates in the output directory of the kernel,
even when building external modules. This increases the risk of external
module Makefiles attempting to write to the kernel directory.
This commit switches the working directory to the external module
directory, allowing the removal of the $(KBUILD_EXTMOD)/ prefix from
some build artifacts.
The command for building external modules maintains backward
compatibility, but Makefiles that rely on working in the kernel
directory may break. In such cases, $(objtree) and $(srctree) should
be used to refer to the output and source directories of the kernel.
The appearance of the build log will change as follows:
[Before]
$ make -C /path/to/my/linux M=/path/to/my/externel/module
make: Entering directory '/path/to/my/linux'
CC [M] /path/to/my/externel/module/helloworld.o
MODPOST /path/to/my/externel/module/Module.symvers
CC [M] /path/to/my/externel/module/helloworld.mod.o
CC [M] /path/to/my/externel/module/.module-common.o
LD [M] /path/to/my/externel/module/helloworld.ko
make: Leaving directory '/path/to/my/linux'
[After]
$ make -C /path/to/my/linux M=/path/to/my/externel/module
make: Entering directory '/path/to/my/linux'
make[1]: Entering directory '/path/to/my/externel/module'
CC [M] helloworld.o
MODPOST Module.symvers
CC [M] helloworld.mod.o
CC [M] .module-common.o
LD [M] helloworld.ko
make[1]: Leaving directory '/path/to/my/externel/module'
make: Leaving directory '/path/to/my/linux'
Printing "Entering directory" twice is cumbersome. This will be
addressed later.
Signed-off-by: Masahiro Yamada <masahiroy@xxxxxxxxxx>
Since this change I have been observing the following build error when
building an external module ...
MODPOST Module.symvers
ERROR: modpost: drivers/gpu/host1x/host1x: 'host1x_device_init' exported
twice. Previous export was in drivers/gpu/host1x/host1x.ko
ERROR: modpost: drivers/gpu/host1x/host1x: 'host1x_device_exit' exported
twice. Previous export was in drivers/gpu/host1x/host1x.ko
Now host1x is an upstream driver, but I have a local copy that using to
stage development changes (and avoid polluting the upstream driver).
Plus I can swap between which version I am using on a live system.
What I noticed is that previously the Modules.symvers for the external
module had the full path of the external module for the name. However,
now the name is just the relative path and in this case
'drivers/gpu/host1x/host1x'. Hence, this clashes with the in-kernel
driver and we get the 'exported twice' error.
I have been looking to see if there is a way to fix this because it has
been a useful feature to override an upstream driver with a locally
modified version.
I do not know how to reproduce it.
if (s && (!external_module || s->module->is_vmlinux || s->module == mod)) {
is not checking the module path at all.
I do not understand why it was affected.
So this is not explicitly checking the path, but comparing the contents
of the Module.symvers before and after this change for the external
module I see ...
$ grep -r host1x_device_init Module.symvers
0x00000000 host1x_device_init /absolute/path/to/drivers/gpu/host1x/host1x EXPORT_SYMBOL
And now I see ...
$ grep -r host1x_device_init Module.symvers
0x00000000 host1x_device_init drivers/gpu/host1x/host1x EXPORT_SYMBOL
So the problem is that now there is no longer an absolute path in the
external modules Module.symvers and so conflicts with the kernel's.
Does that make sense?
As I said, I do not know how to reproduce it.
Please provide the steps to reproduce it.
Got it! The steps would be ...
1. Create an external module by copying using an existing upstream
driver (such as host1x).
2. Create a new external module that uses the external module from step
1 and uses KBUILD_EXTRA_SYMBOLS to reference the Module.symvers for
the driver in step 1.
Thanks!
Jon
--
nvpublic
