On Wed, Jul 19, 2023 at 4:10 PM Petr Gotthard
<[email protected]> wrote:
>
> Thanks Bruce,
>
> > -----Original Message-----
> > From: Bruce Ashfield <[email protected]>
> > Sent: Wednesday, July 19, 2023 7:44 PM
> > To: Petr Gotthard <[email protected]>
> > Cc: [email protected]
> > Subject: Re: [OE-core] make-mod-scripts doesn't know KERNEL_LOCALVERSION
> >
> > Hmm.
> >
> > I explicitly tested this scenario to make sure it worked, since you run
> > into the
> > same issue when building modules on-target.
> >
> > make-mod-scripts is running out of the same SCM as the main kernel build,
> > so it
> > should match, and did in my testing (otherwise lttng-modules wouldn't work).
> >
> > Can you send the exact steps, which kernel recipe you are using, etc.
> > That way I can reproduce the problem locally.
> >
>
> I am using an AM335x with meta-ti (latest master). I think that the
> "beaglebone" might be close enough.
> I did not set any kernel versions explicitly. The KERNEL_LOCALVERSION is set
> by the meta-ti itself in their setup-defconfig.inc:
> https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/recipes-kernel/linux/setup-defconfig.inc
I'm not familiar with what meta-ti's recipes do with respect to kernel
configuration, so I'm only commenting on what I just skimmed from the
link you provided.
Not directly related, but what is going on with .scmversion in that
.inc, will probably break in kernels 6.3+, which is what I'm trying to
head off with the movement of KERNEL_LOCALVERSION/LOCALVERSION to the
base class, it needs to be visible in multiple places.
>
> The kernel is "linux-ti-staging_6.1" with quite standard settings. Recently I
> did explicitly set
> CONFIG_LOCALVERSION_AUTO=n
> which was "y" by default. With the default "y" setting I was getting a kernel
> version with two identical suffixes ("6.1.33-g8f7f371be2-g8f7f371be2",
> whereas the make-mod-scripts used "6.1.33-g8f7f371be2").
Did that only start happening recently ? because with the
localversion_auto and a set .scmversion, that's what I'd expect to
happen (see below).
>
> The out-of-tree modules I am building are using recipes almost identical to
> the "poky/meta-skeleton/recipes-kernel/hello-mod". Again, no kernel version
> specified.
>
> I tried to build the lttng-modules and see the same issue: "modinfo
> lttng-clock.ko" returns
> filename:
> /home/...-linux-gnueabi/lttng-modules/2.13.9-r0/packages-split/kernel-module-lttng-clock-6.1.33-g8f7f371be2/lib/modules/6.1.33-g8f7f371be2/kernel/lttng-modules/lttng-clock.ko
> vermagic: 6.1.33 SMP mod_unload ARMv7 p2v8
>
> which indicates the vermagic (without the -gxxxx sufix) is different to the
> kernel version (with the sufix).
>
The more globally unset LOCALVERSION will be picked up by the kernel
build (as invoked by the kernel or make-mod-scripts), and yes, will
inhibit scm querying.
The previous method was only working with some good luck (in general,
not related to anything meta-ti is doing). That configure in meta-ti
is shooting right through the middle and hence why everything is
lining up as the unset LOCALVERSION should actually be getting a "+" ,
but if CONFIG_LOCALVERSION_AUTO is set, it won't actually run the code
that queries the scm, which makes the .scmversion file what is picked
up. It's all rather fragile :)
I'm curious if on-target module builds work on those boards, since as
near as I can tell the versions won't match (as the .scmversion file
isn't captured, so the vermagic will be different).
As a workaround, it should be possible to either set the LOCALVERSION
globally (or duplicate the variable to make-mod-scripts), so it'll be
the same, or it needs LOCALVERSION be completely unset in
make-mod-scripts, so the kernel localversion script won't pick it up
at all (and use the .scm querying to match).
Let me run some tests on a modified 6.1 linux-yocto and get back to
you. I should be able to mock up a similar localversion configuration.
There are options like using a localversion file, but I'd rather avoid
that if possible, since it'll surely break some other use cases, and
would have to be added to the artifacts for on-target/SDK builds, etc.
Bruce
>
> Petr
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184616):
https://lists.openembedded.org/g/openembedded-core/message/184616
Mute This Topic: https://lists.openembedded.org/mt/100240236/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
