lttng-modules: Fix compilation with our Android Frankenkernels

[Herrie82]

Our Android Frankenkernels have some patches that aren't in mainline kernel or landed in a newer version, so lttng's kernel version check isn't valid.

Fixes the following for Mido, Rosy, Sargo and Tissot:

In file included from /media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/../../include/lttng/define_trace.h:87,
from /media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/../../include/instrumentation/events/sched.h:729,
from /media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/lttng-probe-sched.c:28:
/media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/../../include/lttng/tracepoint-event-impl.h:133:6: error: conflicting types for 'trace_sched_migrate_task'; have 'void(struct task_struct *, int)'
133 | void trace_##_name(proto);
| ^~~~~~
/media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/../../include/lttng/tracepoint-event-impl.h:45:9: note: in expansion of macro 'LTTNG_TRACEPOINT_EVENT_INSTANCE_MAP'
45 | LTTNG_TRACEPOINT_EVENT_INSTANCE_MAP(map, name, map, PARAMS(proto), PARAMS(args))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/../../include/lttng/tracepoint-event-impl.h:87:9: note: in expansion of macro 'LTTNG_TRACEPOINT_EVENT_MAP'
87 | LTTNG_TRACEPOINT_EVENT_MAP(name, name,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
/media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/../../include/instrumentation/events/sched.h:435:1: note: in expansion of macro 'LTTNG_TRACEPOINT_EVENT'
435 | LTTNG_TRACEPOINT_EVENT(sched_migrate_task,
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from /media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work-shared/sargo/kernel-source/include/trace/events/sched.h:8,
from /media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/lttng-probe-sched.c:17:
/media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work-shared/sargo/kernel-source/include/linux/tracepoint.h:183:28: note: previous definition of 'trace_sched_migrate_task' with type 'void(struct task_struct *, int, unsigned int)'
183 | static inline void trace##name(proto)
| ^~~~~~
/media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work-shared/sargo/kernel-source/include/linux/tracepoint.h:348:9: note: in expansion of macro '__DECLARE_TRACE'
348 | _DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),
| ^~~~~~~~~~~~~~~
/media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work-shared/sargo/kernel-source/include/linux/tracepoint.h:484:9: note: in expansion of macro 'DECLARE_TRACE'
484 | DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
| ^~~~~~~~~~~~~
/media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work-shared/sargo/kernel-source/include/trace/events/sched.h:872:1: note: in expansion of macro 'TRACE_EVENT'
872 | TRACE_EVENT(sched_migrate_task,
| ^~~~~~~~~~~
In file included from /media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/../../include/lttng/define_trace.h:87,
from /media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/../../include/instrumentation/events/mm_vmscan.h:854,
from /media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/lttng-probe-vmscan.c:29:
/media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/../../include/lttng/tracepoint-event-impl.h:133:6: error: conflicting types for 'trace_mm_vmscan_lru_isolate'; have 'void(int, int, long unsigned int, long unsigned int, long unsigned int, isolate_mode_t, int)' {aka 'void(int, int, long unsigned int, long unsigned int, long unsigned int, unsigned int, int)'}
133 | void trace##_name(_proto);
| ^~~~~~
/media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/../../include/lttng/tracepoint-event-impl.h:98:9: note: in expansion of macro 'LTTNG_TRACEPOINT_EVENT_INSTANCE_MAP'
98 | LTTNG_TRACEPOINT_EVENT_INSTANCE_MAP(template, name, name, PARAMS(proto), PARAMS(args))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/../../include/instrumentation/events/mm_vmscan.h:454:1: note: in expansion of macro 'LTTNG_TRACEPOINT_EVENT_INSTANCE'
454 | LTTNG_TRACEPOINT_EVENT_INSTANCE(mm_vmscan_lru_isolate_template, mm_vmscan_lru_isolate,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work-shared/sargo/kernel-source/include/trace/events/vmscan.h:8,
from /media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work/sargo-webos-linux/lttng-modules/2.13.12/lttng-modules-2.13.12/src/probes/lttng-probe-vmscan.c:18:
/media/herrie/LuneOS/scarthgap/webos-ports/tmp-glibc/work-shared/sargo/kernel-source/include/linux/tracepoint.h:183:28: note: previous definition of 'trace_mm_vmscan_lru_isolate' with type 'void(int, int, long unsigned int, long unsigned int, long unsigned int, long unsigned int, isolate_mode_t, int)' {aka 'void(int, int, long unsigned int, long unsigned int, long unsigned int, long unsigned int, unsigned int, int)'}

[Herrie82]

@shr-project Build tested on Tissot & Sargo. Will test mido-halium and Rosy as well just to be sure, but based on code should work. Though Rosy is on 3.18 still it seems.

[Tofee]

Rosy has been mainlined, so it's not an issue anymore.

[shr-project]

2024-05-10.log:
08:19 < Herrie> JaMa: Found a fix instead
08:19 < Herrie> This offending commit: shr-distribution/linux@dddcab7
08:20 < Herrie> Introduces load in sched_migrate_task (seems msm arch specific)....
08:20 < Herrie> So probably Tissot, Mido, Rosy and Sargo only
08:20 < Herrie> The other error is due to incorrect kernel version check which is set to 4.11 while it should be 4.9 for this for our kernels
08:20 < Herrie> I'll prepare some patches
10:17 < Herrie> PR sent, build testing 2 more targets
10:31 < Herrie> rosy and mido-halium fail with kernel compilation, will look for some fixes
10:38 < Herrie> For Rosy got "Error: junk at end of line"
10:38 < Herrie> I guess we need something like: shr-distribution/linux@d4d4cae
10:53 < Herrie> Seems lttng-modules isn't very happy with Rosy's 3.18 kernel which is expected
10:59 < Herrie> Seems we should build it only for some machines
10:59 < Herrie> And skip our 3.x ones
11:05 < JaMa> good, thanks
11:10 < Herrie> How to achieve above: Work with COMPATIBLE_MACHINE or you have another idea?
11:12 < JaMa> it would still cause pmtrace to be MACHINE_ARCH with lttng-modules removed from RDEPENDS only for 3.x MACHINEs
11:12 < JaMa> so there isn't a "right" solution
11:14 < Herrie> JaMa: Well anyway it would rebuild many things probably due to glibc compatibility?
11:14 < Herrie> Only aarch64 with 3.x kernel is Rosy
11:14 < Herrie> Others are on 4.x
11:15 < Herrie> Rosy is Tofe's "baby"
11:15 < Herrie> I guess we could upgrade kernel, move to mainline
11:18 < JaMa> "rebuild many things probably due to glibc compatibility" what you mean?
11:22 < Herrie> I mean doesn't a lot of things get rebuild anyway already?
11:24 < JaMa> for each MACHINE? no
11:24 < JaMa> as long as they are using the same TUNE_PKGARCH they should reuse most of the stuff
11:25 < Herrie> The lttng-modules are rebuild for each target anyway currently
11:25 < Herrie> So it would be pmtrace then only?
11:26 < Herrie> And everything that depends on it? Which is appinstalld2 and umediaserver by the looks of it
11:26 < JaMa> lttng-modules yes (because of your .patch files being MACHINE specific now), but now also pmtrace and all the things depending on pmtrace or webruntime with lttng enabled webruntime.inc:PACKAGECONFIG[lttng] = "use_lttng=true,use_lttng=false,lttng-ust,lttng-tools lttng-modules babeltrace"
11:27 < JaMa> and recursively everything depending on appinstalld2 and umediaserver and so on
11:32 < Herrie> Not great
11:35 < JaMa> indeed
11:37 < JaMa> it would be more efficient to revert the patches from MSM kernels (I guess they backported it from 4.11 to 4.9)
11:38 < JaMa> or change the check to 4.9 for all MACHINES (which isn't technically correct) but as long as we don't have any other machine with kernel between 4.9 and 4.11 which doesn't have this backport it should build and it wouldn't cause lttng-modules to became MACHINE_ARCH
11:41 < Herrie> JaMa: Yeah that would work, however lttng-modules has a minimal 4.4 kernel requirement now
11:41 < Herrie> So our 3.x kernels still will fail to build
11:43 < JaMa> ah right

[Tofee]

May I propose another, more radical approach to this issue here, after having gone through a build error with tenderloin-halium.
As @Herrie82 said, our Halium kernels are old, and often heavily patched. Building lttng-module for them makes little sense IMHO.

In OSE, the webos-lttng class takes charge of adding needed lttng DEPENDS and RDEPENDS to the recipes that include it, based on the WEBOS_LTTNG_ENABLED distro variable.
By default it is disabled, and lttng shouldn't be required in that case.

However, in pmtrace.bb, there is both the inherit on webos-lttng, and the DEPENDS and RDEPENDS on lttng harcoded in the recipe. This looks like a mistake, only the inherit should be needed here.
I removed manually these DEPENDS and RDEPENDS from pmtrace.bb, and could build tenderloin-halium successfully.

Maybe the easiest way to go is to patch pmtrace.bb (maybe via a bbappend) to remove any lttng reference from DEPENDS and RDEPENDS ?