On Thu, Dec 12, 2024 at 3:00 PM Jon Hunter <jonathanh@xxxxxxxxxx> wrote:
>
>
> 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
OK, now I understand, and posted a patch.
Thanks.
--
Best Regards
Masahiro Yamada
