[PATCH 0/4] linux-yocto-dev: dev and supporting recipes updates

[PATCH 0/4] linux-yocto-dev: dev and supporting recipes updates

[Bruce Ashfield]

From: Bruce Ashfield <bruce.ashfield@gmail.com>

Richard,

Continuing on the kenrel update path, I've built, booted and run
core-image-kernel-dev on all the supported architectures for v5.14-rcX.

I've pushed the kernel changes, and here are the supporting updaes.
lttng-modules is of course involved, and on that front rather than
backporting patches ot the 2.12.x series, I've moved it to 2.13 (the
latest release), since that will give us better support and more
forward compatibility.

Cheers,

Bruce

The following changes since commit bc65a37ef50faba339fb54d6a89ef9da0298bbbe:

  package: Fix overrides converion issue with PKGSIZE (2021-08-17 09:53:04 +0100)

are available in the Git repository at:

  git://git.yoctoproject.org/poky-contrib zedd/kernel-dev
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-dev

Bruce Ashfield (4):
  linux-yocto-dev: bump to v5.14+
  lttng-modules: update to 2.13.0
  kernel-devsrc: 5.14+ updates
  kernel-devsrc: fix 5.14+ objtool compilation

 meta/recipes-kernel/linux/kernel-devsrc.bb    | 10 +++---
 meta/recipes-kernel/linux/linux-yocto-dev.bb  |  2 +-
 ...fail-if-CONFIG_TRACEPOINTS-is-not-en.patch | 32 ++++++-------------
 ...ules_2.12.6.bb => lttng-modules_2.13.0.bb} |  6 ++--
 4 files changed, 20 insertions(+), 30 deletions(-)
 rename meta/recipes-kernel/lttng/{lttng-modules_2.12.6.bb => lttng-modules_2.13.0.bb} (88%)

-- 
2.19.1

[PATCH 1/4] linux-yocto-dev: bump to v5.14+

[Bruce Ashfield]

From: Bruce Ashfield <bruce.ashfield@gmail.com>

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 28a255a0c0..0911787009 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -30,7 +30,7 @@ SRC_URI = "git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name
 SRCREV_machine ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
 SRCREV_meta ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
 
-LINUX_VERSION ?= "5.13+"
+LINUX_VERSION ?= "5.14+"
 LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-- 
2.19.1

[PATCH 2/4] lttng-modules: update to 2.13.0

[Bruce Ashfield]

From: Bruce Ashfield <bruce.ashfield@gmail.com>

Updating to 2.13.0, so we can pick up the latest -stable and
support for 5.14+ kernels.

We refresh one patch for new context, and update the LICENSE
checksum due to commit 2df37e95fa4303 [Cleanup: Move headers from
toplevel to include/lttng/]. which impacted the LICENSE file (but
licensing is the same).

MODULES_MODULE_SYMVERS_LOCATION must also be specified in this
release, as the lttng build has moved the module target to a
'src' subdirectory.

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---
 ...fail-if-CONFIG_TRACEPOINTS-is-not-en.patch | 32 ++++++-------------
 ...ules_2.12.6.bb => lttng-modules_2.13.0.bb} |  6 ++--
 2 files changed, 14 insertions(+), 24 deletions(-)
 rename meta/recipes-kernel/lttng/{lttng-modules_2.12.6.bb => lttng-modules_2.13.0.bb} (88%)

diff --git a/meta/recipes-kernel/lttng/lttng-modules/Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch b/meta/recipes-kernel/lttng/lttng-modules/Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch
index e411242272..a852834344 100644
--- a/meta/recipes-kernel/lttng/lttng-modules/Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch
+++ b/meta/recipes-kernel/lttng/lttng-modules/Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch
@@ -13,37 +13,25 @@ available, allowing it to be kept being pulled by default.
 Upstream-Status: Inappropriate [embedded specific]
 
 Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
+[bva: modified for lttng-modules 2.13+ context]
+Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
 ---
  Makefile | 9 +++++----
  1 file changed, 5 insertions(+), 4 deletions(-)
 
-diff --git a/Makefile b/Makefile
-index 8602649..75550cc 100644
---- a/Makefile
-+++ b/Makefile
-@@ -8,10 +8,7 @@ ifneq ($(KERNELRELEASE),)
-   # and defines the modules to be built.
+Index: lttng-modules-2.13.0/Makefile
+===================================================================
+--- lttng-modules-2.13.0.orig/Makefile
++++ lttng-modules-2.13.0/Makefile
+@@ -7,6 +7,11 @@
  
-   ifdef CONFIG_LOCALVERSION	# Check if dot-config is included.
--    ifeq ($(CONFIG_TRACEPOINTS),)
--      $(error The option CONFIG_TRACEPOINTS needs to be enabled in your kernel configuration)
--    endif # CONFIG_TRACEPOINTS
--  endif # ifdef CONFIG_LOCALVERSION
-+    ifneq ($(CONFIG_TRACEPOINTS),)
- 
-   TOP_LTTNG_MODULES_DIR := $(shell dirname $(lastword $(MAKEFILE_LIST)))
- 
-@@ -94,6 +91,10 @@ ifneq ($(KERNELRELEASE),)
-   obj-$(CONFIG_LTTNG) += lib/
-   obj-$(CONFIG_LTTNG) += tests/
+ obj-$(CONFIG_LTTNG) += src/
  
-+    else
++  ifdef CONFIG_LOCALVERSION	# Check if dot-config is included.
++    ifneq ($(CONFIG_TRACEPOINTS),)
 +      $(warning The option CONFIG_TRACEPOINTS needs to be enabled in your kernel configuration)
 +    endif # CONFIG_TRACEPOINTS
 +  endif # ifdef CONFIG_LOCALVERSION
  else # KERNELRELEASE
  
  # This part of the Makefile is used when the 'make' command is runned in the
--- 
-2.1.4
-
diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.12.6.bb b/meta/recipes-kernel/lttng/lttng-modules_2.13.0.bb
similarity index 88%
rename from meta/recipes-kernel/lttng/lttng-modules_2.12.6.bb
rename to meta/recipes-kernel/lttng/lttng-modules_2.13.0.bb
index c46faaee58..b95d7ecaaf 100644
--- a/meta/recipes-kernel/lttng/lttng-modules_2.12.6.bb
+++ b/meta/recipes-kernel/lttng/lttng-modules_2.13.0.bb
@@ -3,7 +3,7 @@ SUMMARY = "Linux Trace Toolkit KERNEL MODULE"
 DESCRIPTION = "The lttng-modules 2.0 package contains the kernel tracer modules"
 HOMEPAGE = "https://lttng.org/"
 LICENSE = "LGPLv2.1 & GPLv2 & MIT"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=3f882d431dc0f32f1f44c0707aa41128"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=0464cff101a009c403cd2ed65d01d4c4"
 
 inherit module
 
@@ -13,12 +13,14 @@ SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
            file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch \
            "
 
-SRC_URI[sha256sum] = "95ac2a2cf92d85d23ffbdaca6a1ec0d7c167211d1e0fb850ab90004a3f475eaa"
+SRC_URI[sha256sum] = "5ebf2b3cd128b3a1c8afaea1e98d5a6f7f0676fd524fcf72361c34d9dc603356"
 
 export INSTALL_MOD_DIR="kernel/lttng-modules"
 
 EXTRA_OEMAKE += "KERNELDIR='${STAGING_KERNEL_DIR}'"
 
+MODULES_MODULE_SYMVERS_LOCATION = "src"
+
 do_install:append() {
 	# Delete empty directories to avoid QA failures if no modules were built
 	find ${D}/${nonarch_base_libdir} -depth -type d -empty -exec rmdir {} \;
-- 
2.19.1

[PATCH 3/4] kernel-devsrc: 5.14+ updates

[Bruce Ashfield]

From: Bruce Ashfield <bruce.ashfield@gmail.com>

commit 6218d0f6b8dec [x86/syscalls: Switch to generic syscalltbl.sh]
means that x86 no longer has a syscall script to copy, which causes
a build error.

We already copy the generic syscall script (in scripts), so we just
catch errors for the copies to support older and 5.14+ kernels in
the same devsrc recipe.

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---
 meta/recipes-kernel/linux/kernel-devsrc.bb | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 3b5fdda773..23de1a4917 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -220,10 +220,10 @@ do_install() {
 
 	if [ "${ARCH}" = "x86" ]; then
 	    # files for 'make prepare' to succeed with kernel-devel
-	    cp -a --parents $(find arch/x86 -type f -name "syscall_32.tbl") $kerneldir/build/
-	    cp -a --parents $(find arch/x86 -type f -name "syscalltbl.sh") $kerneldir/build/
-	    cp -a --parents $(find arch/x86 -type f -name "syscallhdr.sh") $kerneldir/build/
-	    cp -a --parents $(find arch/x86 -type f -name "syscall_64.tbl") $kerneldir/build/
+	    cp -a --parents $(find arch/x86 -type f -name "syscall_32.tbl") $kerneldir/build/ 2>/dev/null || :
+	    cp -a --parents $(find arch/x86 -type f -name "syscalltbl.sh") $kerneldir/build/ 2>/dev/null || :
+	    cp -a --parents $(find arch/x86 -type f -name "syscallhdr.sh") $kerneldir/build/ 2>/dev/null || :
+	    cp -a --parents $(find arch/x86 -type f -name "syscall_64.tbl") $kerneldir/build/ 2>/dev/null || :
 	    cp -a --parents arch/x86/tools/relocs_32.c $kerneldir/build/
 	    cp -a --parents arch/x86/tools/relocs_64.c $kerneldir/build/
 	    cp -a --parents arch/x86/tools/relocs.c $kerneldir/build/
-- 
2.19.1

[PATCH 4/4] kernel-devsrc: fix 5.14+ objtool compilation

[Bruce Ashfield]

From: Bruce Ashfield <bruce.ashfield@gmail.com>

In v5.14+, x86 requires not just elfutils, but the elf headers
on the target to build objtool (required for 'scripts parepare'),
so we tweak our RDEPENDS to ensure that the right headers are
on the target.

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---
 meta/recipes-kernel/linux/kernel-devsrc.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 23de1a4917..d39573965f 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -322,7 +322,7 @@ RDEPENDS:${PN} = "bc python3 flex bison ${TCLIBC}-utils"
 # 4.15+ needs these next two RDEPENDS
 RDEPENDS:${PN} += "openssl-dev util-linux"
 # and x86 needs a bit more for 4.15+
-RDEPENDS:${PN} += "${@bb.utils.contains('ARCH', 'x86', 'elfutils', '', d)}"
+RDEPENDS:${PN} += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-dev', '', d)}"
 # 5.8+ needs gcc-plugins libmpc-dev
 RDEPENDS:${PN} += "gcc-plugins libmpc-dev"
 # 5.13+ needs awk for arm64
-- 
2.19.1

Re: [OE-core] [PATCH 2/4] lttng-modules: update to 2.13.0

[Andrey Zhizhikin]

Hello Bruce,

On Tue, Aug 17, 2021 at 5:27 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> From: Bruce Ashfield <bruce.ashfield@gmail.com>
>
> Updating to 2.13.0, so we can pick up the latest -stable and
> support for 5.14+ kernels.
>
> We refresh one patch for new context, and update the LICENSE
> checksum due to commit 2df37e95fa4303 [Cleanup: Move headers from
> toplevel to include/lttng/]. which impacted the LICENSE file (but
> licensing is the same).

I'm seeing a build failure with this new LTTng and CONFIG_TRACEPOINTS
not enabled on the kernel 5.13.12. The failure comes from the Kbuild,
which does not demote the missing trace point config option from error
to warning. There is a patch file already in the layer, but it is only
appended to the 'class-devupstream' and is missing in the SRC_URI.

I was going to submit the patch to recipe to have it included, but
testing the build stage with this patch included I'm seeing a lot of
other errors then, something like:

lttng-modules-2.13.0/src/lttng-tracepoint.c:227:36: error: 'struct
module' has no member named 'num_tracepoints'
-- or --
src/probes/../../include/instrumentation/events/rpc.h:208:36: error:
implicit declaration of function 'rpc_qname'
[-Werror=implicit-function-declaration]

and the list goes on... :/

Have you seen this during testing of this new version? Any advise on
where to look next?

>
> MODULES_MODULE_SYMVERS_LOCATION must also be specified in this
> release, as the lttng build has moved the module target to a
> 'src' subdirectory.
>
> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
> ---
>  ...fail-if-CONFIG_TRACEPOINTS-is-not-en.patch | 32 ++++++-------------
>  ...ules_2.12.6.bb => lttng-modules_2.13.0.bb} |  6 ++--
>  2 files changed, 14 insertions(+), 24 deletions(-)
>  rename meta/recipes-kernel/lttng/{lttng-modules_2.12.6.bb => lttng-modules_2.13.0.bb} (88%)
>
>


-- 
Regards,
Andrey.

Re: [OE-core] [PATCH 2/4] lttng-modules: update to 2.13.0

[Bruce Ashfield]

On Fri, Aug 20, 2021 at 7:13 AM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
>
> Hello Bruce,
>
> On Tue, Aug 17, 2021 at 5:27 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> >
> > From: Bruce Ashfield <bruce.ashfield@gmail.com>
> >
> > Updating to 2.13.0, so we can pick up the latest -stable and
> > support for 5.14+ kernels.
> >
> > We refresh one patch for new context, and update the LICENSE
> > checksum due to commit 2df37e95fa4303 [Cleanup: Move headers from
> > toplevel to include/lttng/]. which impacted the LICENSE file (but
> > licensing is the same).
>
> I'm seeing a build failure with this new LTTng and CONFIG_TRACEPOINTS
> not enabled on the kernel 5.13.12. The failure comes from the Kbuild,
> which does not demote the missing trace point config option from error
> to warning. There is a patch file already in the layer, but it is only
> appended to the 'class-devupstream' and is missing in the SRC_URI.

Hmmm. I ported the original patch, but yes, that Kbuild patch is also
needed (and it is my own patch no less).

I was just updating the devupstream version yesterday, and ran across
that patch.

None of the oe-core qemu* BSPs I test against have a disabled
tracepoint configuration, so I didn't run into that.

I have the bumped devupstream version and the ported patch done
locally, I can send it out shortly, but it sounds like you've already
done that, so I can sit on that change.

>
> I was going to submit the patch to recipe to have it included, but
> testing the build stage with this patch included I'm seeing a lot of
> other errors then, something like:
>
> lttng-modules-2.13.0/src/lttng-tracepoint.c:227:36: error: 'struct
> module' has no member named 'num_tracepoints'
> -- or --
> src/probes/../../include/instrumentation/events/rpc.h:208:36: error:
> implicit declaration of function 'rpc_qname'
> [-Werror=implicit-function-declaration]
>
> and the list goes on... :/
>
> Have you seen this during testing of this new version? Any advise on
> where to look next?

Not really. I end up updating lttng frequently, due to my constant
work on new kernel versions, but I'm not a lttng expert by any
definition.

The smoke tests passed when I ran the tests, I'll poke around a bit
and see if I can come up with any ideas (since clearly, our kernel
configurations are quite different, given that I never did run into
that patch not being in devupstream).

Bruce

>
> >
> > MODULES_MODULE_SYMVERS_LOCATION must also be specified in this
> > release, as the lttng build has moved the module target to a
> > 'src' subdirectory.
> >
> > Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
> > ---
> >  ...fail-if-CONFIG_TRACEPOINTS-is-not-en.patch | 32 ++++++-------------
> >  ...ules_2.12.6.bb => lttng-modules_2.13.0.bb} |  6 ++--
> >  2 files changed, 14 insertions(+), 24 deletions(-)
> >  rename meta/recipes-kernel/lttng/{lttng-modules_2.12.6.bb => lttng-modules_2.13.0.bb} (88%)
> >
> >
>
>
> --
> Regards,
> Andrey.



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [OE-core] [PATCH 2/4] lttng-modules: update to 2.13.0

[Andrey Zhizhikin]

On Fri, Aug 20, 2021 at 2:57 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> On Fri, Aug 20, 2021 at 7:13 AM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> >
> > Hello Bruce,
> >
> > On Tue, Aug 17, 2021 at 5:27 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> > >
> > > From: Bruce Ashfield <bruce.ashfield@gmail.com>
> > >
> > > Updating to 2.13.0, so we can pick up the latest -stable and
> > > support for 5.14+ kernels.
> > >
> > > We refresh one patch for new context, and update the LICENSE
> > > checksum due to commit 2df37e95fa4303 [Cleanup: Move headers from
> > > toplevel to include/lttng/]. which impacted the LICENSE file (but
> > > licensing is the same).
> >
> > I'm seeing a build failure with this new LTTng and CONFIG_TRACEPOINTS
> > not enabled on the kernel 5.13.12. The failure comes from the Kbuild,
> > which does not demote the missing trace point config option from error
> > to warning. There is a patch file already in the layer, but it is only
> > appended to the 'class-devupstream' and is missing in the SRC_URI.
>
> Hmmm. I ported the original patch, but yes, that Kbuild patch is also
> needed (and it is my own patch no less).
>
> I was just updating the devupstream version yesterday, and ran across
> that patch.
>
> None of the oe-core qemu* BSPs I test against have a disabled
> tracepoint configuration, so I didn't run into that.

I'd try to enable it locally on my end, just to see if LTTng would
build with trace points enabled in the kernel config.

>
> I have the bumped devupstream version and the ported patch done
> locally, I can send it out shortly, but it sounds like you've already
> done that, so I can sit on that change.

Please go ahead and send out your version, I'll be figuring out those
build errors on my end, and it might take some time...

>
> >
> > I was going to submit the patch to recipe to have it included, but
> > testing the build stage with this patch included I'm seeing a lot of
> > other errors then, something like:
> >
> > lttng-modules-2.13.0/src/lttng-tracepoint.c:227:36: error: 'struct
> > module' has no member named 'num_tracepoints'
> > -- or --
> > src/probes/../../include/instrumentation/events/rpc.h:208:36: error:
> > implicit declaration of function 'rpc_qname'
> > [-Werror=implicit-function-declaration]
> >
> > and the list goes on... :/
> >
> > Have you seen this during testing of this new version? Any advise on
> > where to look next?
>
> Not really. I end up updating lttng frequently, due to my constant
> work on new kernel versions, but I'm not a lttng expert by any
> definition.

Same here, I just saw the build failure and started to poke around to
see what could be the root cause of it.

Missing KBuild patch was an easy find, but those compiler errors are not...

>
> The smoke tests passed when I ran the tests, I'll poke around a bit
> and see if I can come up with any ideas (since clearly, our kernel
> configurations are quite different, given that I never did run into
> that patch not being in devupstream).
>
> Bruce
>
> >
> > >
> > > MODULES_MODULE_SYMVERS_LOCATION must also be specified in this
> > > release, as the lttng build has moved the module target to a
> > > 'src' subdirectory.
> > >
> > > Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > ---
> > >  ...fail-if-CONFIG_TRACEPOINTS-is-not-en.patch | 32 ++++++-------------
> > >  ...ules_2.12.6.bb => lttng-modules_2.13.0.bb} |  6 ++--
> > >  2 files changed, 14 insertions(+), 24 deletions(-)
> > >  rename meta/recipes-kernel/lttng/{lttng-modules_2.12.6.bb => lttng-modules_2.13.0.bb} (88%)
> > >
> > >
> >
> >
> > --
> > Regards,
> > Andrey.
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



-- 
Regards,
Andrey.

Re: [OE-core] [PATCH 2/4] lttng-modules: update to 2.13.0

[Andrey Zhizhikin]

Hello Bruce,

On Fri, Aug 20, 2021 at 3:21 PM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
>
> On Fri, Aug 20, 2021 at 2:57 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> >
> > On Fri, Aug 20, 2021 at 7:13 AM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> > >
> > > Hello Bruce,
> > >
> > > On Tue, Aug 17, 2021 at 5:27 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> > > >
> > > > From: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > >
> > > > Updating to 2.13.0, so we can pick up the latest -stable and
> > > > support for 5.14+ kernels.
> > > >
> > > > We refresh one patch for new context, and update the LICENSE
> > > > checksum due to commit 2df37e95fa4303 [Cleanup: Move headers from
> > > > toplevel to include/lttng/]. which impacted the LICENSE file (but
> > > > licensing is the same).
> > >
> > > I'm seeing a build failure with this new LTTng and CONFIG_TRACEPOINTS
> > > not enabled on the kernel 5.13.12. The failure comes from the Kbuild,
> > > which does not demote the missing trace point config option from error
> > > to warning. There is a patch file already in the layer, but it is only
> > > appended to the 'class-devupstream' and is missing in the SRC_URI.
> >
> > Hmmm. I ported the original patch, but yes, that Kbuild patch is also
> > needed (and it is my own patch no less).
> >
> > I was just updating the devupstream version yesterday, and ran across
> > that patch.
> >
> > None of the oe-core qemu* BSPs I test against have a disabled
> > tracepoint configuration, so I didn't run into that.
>
> I'd try to enable it locally on my end, just to see if LTTng would
> build with trace points enabled in the kernel config.

Just as a follow-up here: when FTRACE (and dependent config options)
is enabled in the kernel - LTTng builds happily. I guess your sanity
build went through with no issues exactly due to the fact that tracing
is enabled in Yocto kernels.

>
> >
> > I have the bumped devupstream version and the ported patch done
> > locally, I can send it out shortly, but it sounds like you've already
> > done that, so I can sit on that change.
>
> Please go ahead and send out your version, I'll be figuring out those
> build errors on my end, and it might take some time...
>
> >
> > >
> > > I was going to submit the patch to recipe to have it included, but
> > > testing the build stage with this patch included I'm seeing a lot of
> > > other errors then, something like:
> > >
> > > lttng-modules-2.13.0/src/lttng-tracepoint.c:227:36: error: 'struct
> > > module' has no member named 'num_tracepoints'
> > > -- or --
> > > src/probes/../../include/instrumentation/events/rpc.h:208:36: error:
> > > implicit declaration of function 'rpc_qname'
> > > [-Werror=implicit-function-declaration]
> > >
> > > and the list goes on... :/
> > >
> > > Have you seen this during testing of this new version? Any advise on
> > > where to look next?
> >
> > Not really. I end up updating lttng frequently, due to my constant
> > work on new kernel versions, but I'm not a lttng expert by any
> > definition.
>
> Same here, I just saw the build failure and started to poke around to
> see what could be the root cause of it.
>
> Missing KBuild patch was an easy find, but those compiler errors are not...
>
> >
> > The smoke tests passed when I ran the tests, I'll poke around a bit
> > and see if I can come up with any ideas (since clearly, our kernel
> > configurations are quite different, given that I never did run into
> > that patch not being in devupstream).
> >
> > Bruce
> >
> > >
> > > >
> > > > MODULES_MODULE_SYMVERS_LOCATION must also be specified in this
> > > > release, as the lttng build has moved the module target to a
> > > > 'src' subdirectory.
> > > >
> > > > Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > > ---
> > > >  ...fail-if-CONFIG_TRACEPOINTS-is-not-en.patch | 32 ++++++-------------
> > > >  ...ules_2.12.6.bb => lttng-modules_2.13.0.bb} |  6 ++--
> > > >  2 files changed, 14 insertions(+), 24 deletions(-)
> > > >  rename meta/recipes-kernel/lttng/{lttng-modules_2.12.6.bb => lttng-modules_2.13.0.bb} (88%)
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Andrey.
> >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
> --
> Regards,
> Andrey.



-- 
Regards,
Andrey.

Re: [OE-core] [PATCH 2/4] lttng-modules: update to 2.13.0

[Bruce Ashfield]

On Fri, Aug 20, 2021 at 10:04 AM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
>
> Hello Bruce,
>
> On Fri, Aug 20, 2021 at 3:21 PM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> >
> > On Fri, Aug 20, 2021 at 2:57 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> > >
> > > On Fri, Aug 20, 2021 at 7:13 AM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> > > >
> > > > Hello Bruce,
> > > >
> > > > On Tue, Aug 17, 2021 at 5:27 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> > > > >
> > > > > From: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > > >
> > > > > Updating to 2.13.0, so we can pick up the latest -stable and
> > > > > support for 5.14+ kernels.
> > > > >
> > > > > We refresh one patch for new context, and update the LICENSE
> > > > > checksum due to commit 2df37e95fa4303 [Cleanup: Move headers from
> > > > > toplevel to include/lttng/]. which impacted the LICENSE file (but
> > > > > licensing is the same).
> > > >
> > > > I'm seeing a build failure with this new LTTng and CONFIG_TRACEPOINTS
> > > > not enabled on the kernel 5.13.12. The failure comes from the Kbuild,
> > > > which does not demote the missing trace point config option from error
> > > > to warning. There is a patch file already in the layer, but it is only
> > > > appended to the 'class-devupstream' and is missing in the SRC_URI.
> > >
> > > Hmmm. I ported the original patch, but yes, that Kbuild patch is also
> > > needed (and it is my own patch no less).
> > >
> > > I was just updating the devupstream version yesterday, and ran across
> > > that patch.
> > >
> > > None of the oe-core qemu* BSPs I test against have a disabled
> > > tracepoint configuration, so I didn't run into that.
> >
> > I'd try to enable it locally on my end, just to see if LTTng would
> > build with trace points enabled in the kernel config.
>
> Just as a follow-up here: when FTRACE (and dependent config options)
> is enabled in the kernel - LTTng builds happily. I guess your sanity
> build went through with no issues exactly due to the fact that tracing
> is enabled in Yocto kernels.

Most likely yes.

As lttng marches on, we need a better solution than attempting to make
it build with the required configurations disabled.

I know that I'm not really enthusiastic about carrying the patches,
and that's why I didn't send my updates yet, since I was pondering
making lttng triggered by a distro feature, so that it just won't be
built in cases where it won't work.

Bruce

>
> >
> > >
> > > I have the bumped devupstream version and the ported patch done
> > > locally, I can send it out shortly, but it sounds like you've already
> > > done that, so I can sit on that change.
> >
> > Please go ahead and send out your version, I'll be figuring out those
> > build errors on my end, and it might take some time...
> >
> > >
> > > >
> > > > I was going to submit the patch to recipe to have it included, but
> > > > testing the build stage with this patch included I'm seeing a lot of
> > > > other errors then, something like:
> > > >
> > > > lttng-modules-2.13.0/src/lttng-tracepoint.c:227:36: error: 'struct
> > > > module' has no member named 'num_tracepoints'
> > > > -- or --
> > > > src/probes/../../include/instrumentation/events/rpc.h:208:36: error:
> > > > implicit declaration of function 'rpc_qname'
> > > > [-Werror=implicit-function-declaration]
> > > >
> > > > and the list goes on... :/
> > > >
> > > > Have you seen this during testing of this new version? Any advise on
> > > > where to look next?
> > >
> > > Not really. I end up updating lttng frequently, due to my constant
> > > work on new kernel versions, but I'm not a lttng expert by any
> > > definition.
> >
> > Same here, I just saw the build failure and started to poke around to
> > see what could be the root cause of it.
> >
> > Missing KBuild patch was an easy find, but those compiler errors are not...
> >
> > >
> > > The smoke tests passed when I ran the tests, I'll poke around a bit
> > > and see if I can come up with any ideas (since clearly, our kernel
> > > configurations are quite different, given that I never did run into
> > > that patch not being in devupstream).
> > >
> > > Bruce
> > >
> > > >
> > > > >
> > > > > MODULES_MODULE_SYMVERS_LOCATION must also be specified in this
> > > > > release, as the lttng build has moved the module target to a
> > > > > 'src' subdirectory.
> > > > >
> > > > > Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > > > ---
> > > > >  ...fail-if-CONFIG_TRACEPOINTS-is-not-en.patch | 32 ++++++-------------
> > > > >  ...ules_2.12.6.bb => lttng-modules_2.13.0.bb} |  6 ++--
> > > > >  2 files changed, 14 insertions(+), 24 deletions(-)
> > > > >  rename meta/recipes-kernel/lttng/{lttng-modules_2.12.6.bb => lttng-modules_2.13.0.bb} (88%)
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Andrey.
> > >
> > >
> > >
> > > --
> > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > thee at its end
> > > - "Use the force Harry" - Gandalf, Star Trek II
> >
> >
> >
> > --
> > Regards,
> > Andrey.
>
>
>
> --
> Regards,
> Andrey.



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II