Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

[Mathieu Desnoyers]

----- On Jun 12, 2019, at 12:51 PM, Adrian Bunk bunk@stusta.de wrote:

> On Tue, Jun 11, 2019 at 11:49:34PM +0100, Richard Purdie wrote:
>> On Tue, 2019-06-11 at 17:03 +0800, zhe.he@windriver.com wrote:
>> > From: He Zhe <zhe.he@windriver.com>
>> > 
>> > For the moment,
>> > 0001~0004 are on master branch only.
>> > 0005~0007 are on stable-2.11 branch, but v2.11 has not been released
>> > yet.
>> > 
>> > Signed-off-by: He Zhe <zhe.he@windriver.com>
>> > ---
>> > v2: Correct a typo in SOB for 0001*.patch
>> 
>> I just discussed this with lttng upstream maintainers a little. We're
>> going to have continual tension between keeping lttng-modules up to
>> date and new kernel versions.
>> 
>> How about we also have a git version of this particular recipe which
>> has a DEFAULT_PREFERENCE = "-1" but people can opt into with a
>> PREFERRED_VERSION when using newer kernels?
> 
> Yocto stable series will ship a _git AUTOREV recipe?
> 
>> That should keep people using very recent kernels happy, let us use a
>> stable release version and avoid us adding/removing large patchsets on
>> a semi regular basis?
>>...
> 
> The semi regular basis is only slightly moved, or how and when will
> replacing the already EOL kernel 5.0 with 5.1 in Yocto be handled?
> 
> IMHO it would be better to acknowledge that this is a case where staying
> at stable release versions is sometimes not the best option, and upgrade
> the normal recipe to -rc releases or even a git snapshot from a more
> recent stable branch when necessary.
> 
> E.g. right now it seems clear that the next Yocto release will have
> to use lttng-modules >= 2.11 in any case for kernel 5.2, so upgrading
> from 2.10.9 to 2.11.0-rc5 would be logical.

Please don't base distributions on -rc tags. They are not meant for this.

We always integrate support for newer kernel versions instrumentation back
into our current stable release. So as soon as 5.2 final comes out, we will
release a 2.10.x version including support for it in lttng-modules.

The current 2.10.10 has commits to support the currently known 5.2-rc
instrumentation changes.

Thanks,

Mathieu


> 
>> Cheers,
>> 
>> Richard
> 
> cu
> Adrian
> 
> --
> 
>       "Is there not promise of rain?" Ling Tan asked suddenly out
>        of the darkness. There had been need of rain for many days.
>       "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

[He Zhe]

On 6/12/19 6:58 PM, Mathieu Desnoyers wrote:
> ----- On Jun 12, 2019, at 12:51 PM, Adrian Bunk bunk-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org wrote:
>
>> On Tue, Jun 11, 2019 at 11:49:34PM +0100, Richard Purdie wrote:
>>> On Tue, 2019-06-11 at 17:03 +0800, zhe.he-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org wrote:
>>>> From: He Zhe <zhe.he-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
>>>>
>>>> For the moment,
>>>> 0001~0004 are on master branch only.
>>>> 0005~0007 are on stable-2.11 branch, but v2.11 has not been released
>>>> yet.
>>>>
>>>> Signed-off-by: He Zhe <zhe.he-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
>>>> ---
>>>> v2: Correct a typo in SOB for 0001*.patch
>>> I just discussed this with lttng upstream maintainers a little. We're
>>> going to have continual tension between keeping lttng-modules up to
>>> date and new kernel versions.
>>>
>>> How about we also have a git version of this particular recipe which
>>> has a DEFAULT_PREFERENCE = "-1" but people can opt into with a
>>> PREFERRED_VERSION when using newer kernels?
>> Yocto stable series will ship a _git AUTOREV recipe?
>>
>>> That should keep people using very recent kernels happy, let us use a
>>> stable release version and avoid us adding/removing large patchsets on
>>> a semi regular basis?
>>> ...
>> The semi regular basis is only slightly moved, or how and when will
>> replacing the already EOL kernel 5.0 with 5.1 in Yocto be handled?
>>
>> IMHO it would be better to acknowledge that this is a case where staying
>> at stable release versions is sometimes not the best option, and upgrade
>> the normal recipe to -rc releases or even a git snapshot from a more
>> recent stable branch when necessary.
>>
>> E.g. right now it seems clear that the next Yocto release will have
>> to use lttng-modules >= 2.11 in any case for kernel 5.2, so upgrading
>> from 2.10.9 to 2.11.0-rc5 would be logical.
> Please don't base distributions on -rc tags. They are not meant for this.
>
> We always integrate support for newer kernel versions instrumentation back
> into our current stable release. So as soon as 5.2 final comes out, we will
> release a 2.10.x version including support for it in lttng-modules.

I'm one of the people who need to use lttng-modules on rc kernel.

>
> The current 2.10.10 has commits to support the currently known 5.2-rc
> instrumentation changes.

Seems v2.10.10 does not contains the 7 needed patches in my v1 for kernel v5.0+.
$ git pull
Already up-to-date.
$ git tag|grep v2.10.10
v2.10.10
$ git tag --contains 92da05ce1f73488a57e7fd79e9c03113cefdb76f
$ git tag --contains d88e2fe5c3ea0d2c3055fba824be17223c418854
$ git tag --contains d6cd2c9598a06f0ba1ba885bbe754e8836528310
$ git tag --contains 2ca0c84f0b4a915c555a0b83102d94ac941619ca
$ git tag --contains da00122ccfae6a73ec859826a0be1cf0902cfd11
v2.11.0-rc5
$ git tag --contains da00122ccfae6a73ec859826a0be1cf0902cfd11
v2.11.0-rc5
$ git tag --contains df0e746a05a267384785d66c9fca947eb4a9e517
v2.11.0-rc5
$ git tag --contains 9f70b60c19abc6dc0811e427ed5da4aa74620aca
v2.11.0-rc5

Thanks,
Zhe

>
> Thanks,
>
> Mathieu
>
>
>>> Cheers,
>>>
>>> Richard
>> cu
>> Adrian
>>
>> --
>>
>>       "Is there not promise of rain?" Ling Tan asked suddenly out
>>        of the darkness. There had been need of rain for many days.
>>       "Only a promise," Lao Er said.
>>                                        Pearl S. Buck - Dragon Seed

-- 

Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

[Mathieu Desnoyers]

----- On Jun 12, 2019, at 1:10 PM, zhe he zhe.he@windriver.com wrote:

> On 6/12/19 6:58 PM, Mathieu Desnoyers wrote:
>> ----- On Jun 12, 2019, at 12:51 PM, Adrian Bunk bunk@stusta.de wrote:
>>
>>> On Tue, Jun 11, 2019 at 11:49:34PM +0100, Richard Purdie wrote:
>>>> On Tue, 2019-06-11 at 17:03 +0800, zhe.he@windriver.com wrote:
>>>>> From: He Zhe <zhe.he@windriver.com>
>>>>>
>>>>> For the moment,
>>>>> 0001~0004 are on master branch only.
>>>>> 0005~0007 are on stable-2.11 branch, but v2.11 has not been released
>>>>> yet.
>>>>>
>>>>> Signed-off-by: He Zhe <zhe.he@windriver.com>
>>>>> ---
>>>>> v2: Correct a typo in SOB for 0001*.patch
>>>> I just discussed this with lttng upstream maintainers a little. We're
>>>> going to have continual tension between keeping lttng-modules up to
>>>> date and new kernel versions.
>>>>
>>>> How about we also have a git version of this particular recipe which
>>>> has a DEFAULT_PREFERENCE = "-1" but people can opt into with a
>>>> PREFERRED_VERSION when using newer kernels?
>>> Yocto stable series will ship a _git AUTOREV recipe?
>>>
>>>> That should keep people using very recent kernels happy, let us use a
>>>> stable release version and avoid us adding/removing large patchsets on
>>>> a semi regular basis?
>>>> ...
>>> The semi regular basis is only slightly moved, or how and when will
>>> replacing the already EOL kernel 5.0 with 5.1 in Yocto be handled?
>>>
>>> IMHO it would be better to acknowledge that this is a case where staying
>>> at stable release versions is sometimes not the best option, and upgrade
>>> the normal recipe to -rc releases or even a git snapshot from a more
>>> recent stable branch when necessary.
>>>
>>> E.g. right now it seems clear that the next Yocto release will have
>>> to use lttng-modules >= 2.11 in any case for kernel 5.2, so upgrading
>>> from 2.10.9 to 2.11.0-rc5 would be logical.
>> Please don't base distributions on -rc tags. They are not meant for this.
>>
>> We always integrate support for newer kernel versions instrumentation back
>> into our current stable release. So as soon as 5.2 final comes out, we will
>> release a 2.10.x version including support for it in lttng-modules.
> 
> I'm one of the people who need to use lttng-modules on rc kernel.
> 
>>
>> The current 2.10.10 has commits to support the currently known 5.2-rc
>> instrumentation changes.
> 
> Seems v2.10.10 does not contains the 7 needed patches in my v1 for kernel v5.0+.
> $ git pull
> Already up-to-date.
> $ git tag|grep v2.10.10
> v2.10.10
> $ git tag --contains 92da05ce1f73488a57e7fd79e9c03113cefdb76f
> $ git tag --contains d88e2fe5c3ea0d2c3055fba824be17223c418854
> $ git tag --contains d6cd2c9598a06f0ba1ba885bbe754e8836528310
> $ git tag --contains 2ca0c84f0b4a915c555a0b83102d94ac941619ca
> $ git tag --contains da00122ccfae6a73ec859826a0be1cf0902cfd11
> v2.11.0-rc5
> $ git tag --contains da00122ccfae6a73ec859826a0be1cf0902cfd11
> v2.11.0-rc5
> $ git tag --contains df0e746a05a267384785d66c9fca947eb4a9e517
> v2.11.0-rc5
> $ git tag --contains 9f70b60c19abc6dc0811e427ed5da4aa74620aca
> v2.11.0-rc5

You're aware that the commit ID changes when we cherry-pick
a commit right ?

Please double-check with the commit names...

Thanks,

Mathieu


> 
> Thanks,
> Zhe
> 
>>
>> Thanks,
>>
>> Mathieu
>>
>>
>>>> Cheers,
>>>>
>>>> Richard
>>> cu
>>> Adrian
>>>
>>> --
>>>
>>>       "Is there not promise of rain?" Ling Tan asked suddenly out
>>>        of the darkness. There had been need of rain for many days.
>>>       "Only a promise," Lao Er said.
> >>                                        Pearl S. Buck - Dragon Seed

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

[He Zhe]

On 6/12/19 7:29 PM, Mathieu Desnoyers wrote:
> ----- On Jun 12, 2019, at 1:10 PM, zhe he zhe.he-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org wrote:
>
>> On 6/12/19 6:58 PM, Mathieu Desnoyers wrote:
>>> ----- On Jun 12, 2019, at 12:51 PM, Adrian Bunk bunk-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org wrote:
>>>
>>>> On Tue, Jun 11, 2019 at 11:49:34PM +0100, Richard Purdie wrote:
>>>>> On Tue, 2019-06-11 at 17:03 +0800, zhe.he-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org wrote:
>>>>>> From: He Zhe <zhe.he-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
>>>>>>
>>>>>> For the moment,
>>>>>> 0001~0004 are on master branch only.
>>>>>> 0005~0007 are on stable-2.11 branch, but v2.11 has not been released
>>>>>> yet.
>>>>>>
>>>>>> Signed-off-by: He Zhe <zhe.he-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
>>>>>> ---
>>>>>> v2: Correct a typo in SOB for 0001*.patch
>>>>> I just discussed this with lttng upstream maintainers a little. We're
>>>>> going to have continual tension between keeping lttng-modules up to
>>>>> date and new kernel versions.
>>>>>
>>>>> How about we also have a git version of this particular recipe which
>>>>> has a DEFAULT_PREFERENCE = "-1" but people can opt into with a
>>>>> PREFERRED_VERSION when using newer kernels?
>>>> Yocto stable series will ship a _git AUTOREV recipe?
>>>>
>>>>> That should keep people using very recent kernels happy, let us use a
>>>>> stable release version and avoid us adding/removing large patchsets on
>>>>> a semi regular basis?
>>>>> ...
>>>> The semi regular basis is only slightly moved, or how and when will
>>>> replacing the already EOL kernel 5.0 with 5.1 in Yocto be handled?
>>>>
>>>> IMHO it would be better to acknowledge that this is a case where staying
>>>> at stable release versions is sometimes not the best option, and upgrade
>>>> the normal recipe to -rc releases or even a git snapshot from a more
>>>> recent stable branch when necessary.
>>>>
>>>> E.g. right now it seems clear that the next Yocto release will have
>>>> to use lttng-modules >= 2.11 in any case for kernel 5.2, so upgrading
>>>> from 2.10.9 to 2.11.0-rc5 would be logical.
>>> Please don't base distributions on -rc tags. They are not meant for this.
>>>
>>> We always integrate support for newer kernel versions instrumentation back
>>> into our current stable release. So as soon as 5.2 final comes out, we will
>>> release a 2.10.x version including support for it in lttng-modules.
>> I'm one of the people who need to use lttng-modules on rc kernel.
>>
>>> The current 2.10.10 has commits to support the currently known 5.2-rc
>>> instrumentation changes.
>> Seems v2.10.10 does not contains the 7 needed patches in my v1 for kernel v5.0+.
>> $ git pull
>> Already up-to-date.
>> $ git tag|grep v2.10.10
>> v2.10.10
>> $ git tag --contains 92da05ce1f73488a57e7fd79e9c03113cefdb76f
>> $ git tag --contains d88e2fe5c3ea0d2c3055fba824be17223c418854
>> $ git tag --contains d6cd2c9598a06f0ba1ba885bbe754e8836528310
>> $ git tag --contains 2ca0c84f0b4a915c555a0b83102d94ac941619ca
>> $ git tag --contains da00122ccfae6a73ec859826a0be1cf0902cfd11
>> v2.11.0-rc5
>> $ git tag --contains da00122ccfae6a73ec859826a0be1cf0902cfd11
>> v2.11.0-rc5
>> $ git tag --contains df0e746a05a267384785d66c9fca947eb4a9e517
>> v2.11.0-rc5
>> $ git tag --contains 9f70b60c19abc6dc0811e427ed5da4aa74620aca
>> v2.11.0-rc5
> You're aware that the commit ID changes when we cherry-pick
> a commit right ?
>
> Please double-check with the commit names...

Sorry, my mistake. They've been there.

Zhe

>
> Thanks,
>
> Mathieu
>
>
>> Thanks,
>> Zhe
>>
>>> Thanks,
>>>
>>> Mathieu
>>>
>>>
>>>>> Cheers,
>>>>>
>>>>> Richard
>>>> cu
>>>> Adrian
>>>>
>>>> --
>>>>
>>>>       "Is there not promise of rain?" Ling Tan asked suddenly out
>>>>        of the darkness. There had been need of rain for many days.
>>>>       "Only a promise," Lao Er said.
>>>>                                        Pearl S. Buck - Dragon Seed

-- 

Re: [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

[Adrian Bunk]

On Wed, Jun 12, 2019 at 06:58:22AM -0400, Mathieu Desnoyers wrote:
>...
> We always integrate support for newer kernel versions instrumentation back
> into our current stable release. So as soon as 5.2 final comes out, we will
> release a 2.10.x version including support for it in lttng-modules.
>...

Did something go wrong with that for 5.1?

This discussion started with patches on top of 2.10.9 for 5.1 support.
If the missing release was just a one-time problem for 5.1,
then the whole problem is usually confined to -rc kernels.
 
> Thanks,
> 
> Mathieu

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-- 

Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

[Mathieu Desnoyers]

----- On Jun 12, 2019, at 3:27 PM, Adrian Bunk bunk@stusta.de wrote:

> On Wed, Jun 12, 2019 at 06:58:22AM -0400, Mathieu Desnoyers wrote:
>>...
>> We always integrate support for newer kernel versions instrumentation back
>> into our current stable release. So as soon as 5.2 final comes out, we will
>> release a 2.10.x version including support for it in lttng-modules.
>>...
> 
> Did something go wrong with that for 5.1?

Only failure to do a timely release on my end, sorry about it. Don't
hesitate to ping me when this happens. The patches were cherry-picked
into the stable-2.10 branch quickly after 5.1 was released (or while in
5.1-rc cycle), but Jonathan reminded me just yesterday that I was overdue
for a release.

> 
> This discussion started with patches on top of 2.10.9 for 5.1 support.
> If the missing release was just a one-time problem for 5.1,
> then the whole problem is usually confined to -rc kernels.

Indeed, I'll try to release stable tags more proactively after a kernel
version comes out in the future.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

[Jonathan Rajotte-Julien]

Hi,

> > Please don't base distributions on -rc tags. They are not meant for this.
> >
> > We always integrate support for newer kernel versions instrumentation back
> > into our current stable release. So as soon as 5.2 final comes out, we will
> > release a 2.10.x version including support for it in lttng-modules.
> 
> I'm one of the people who need to use lttng-modules on rc kernel.

If so, please use a git based recipe building the HEAD of the latest released
stable branch (stable-2.10 currently since 2.11 is in currently in the RC
stage). If you have problem, report them on our mailing list [1] or our bug
tracker [2]. We have extensive CI jobs for lttng-modules against the vanilla
kernel [3] and other usual suspects [4]. We normally catch those problems
quite quickly. Keep in mind that in no way should a production image be built
with a non tagged release.

As for the oe-core recipe, please send us a quick email to let us know, patch
level releases are cheap. Keep in mind that we are chasing a moving target
here.

To add to Mathieu statement, not only do we integrate support for newer kernels into
the current stable branch but also in all the supported stable branch when
possible. The supported stable release are normally the 3 latest minor-level releases.
Currently this set is : 2.8, 2.9, 2.10 .

[1] https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[2] https://bugs.lttng.org/
[3] An example of such job running: https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_master_build-vanilla/648/console
    This job validate that lttng-modules master builds against the following vanilla kernel tags. We have
    similar jobs for master, stable 2.11, stable 2.10, stable 2.9, stable 2.10 lttng-modules branch.
      v3.0.101
      v3.1.10
      v3.2.102
      v3.3.8
      v3.4.113
      v3.5.7
      v3.6.11
      v3.7.10
      v3.8.13
      v3.9.11
      v3.10.108
      v3.11.10
      v3.12.74
      v3.13.11
      v3.14.79
      v3.15.10
      v3.16.68
      v3.17.8
      v3.18.140
      v3.19.8
      v4.0.9
      v4.1.52
      v4.2.8
      v4.3.6
      v4.4.181
      v4.5.7
      v4.6.7
      v4.7.10
      v4.8.17
      v4.9.181
      v4.10.17
      v4.11.12
      v4.12.14
      v4.13.16
      v4.14.125
      v4.15.18
      v4.16.18
      v4.17.19
      v4.18.20
      v4.19.50
      v4.20.17
      v5.0.21
      v5.1.9
      v5.2-rc4
[4] https://ci.lttng.org/view/LTTng-modules/

-- 
Jonathan Rajotte-Julien
EfficiOS
-- 

Re: [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

[Jonathan Rajotte-Julien]

On Wed, Jun 12, 2019 at 10:52:36AM -0400, Jonathan Rajotte-Julien wrote:
> Hi,
> 
> > > Please don't base distributions on -rc tags. They are not meant for this.
> > >
> > > We always integrate support for newer kernel versions instrumentation back
> > > into our current stable release. So as soon as 5.2 final comes out, we will
> > > release a 2.10.x version including support for it in lttng-modules.
> > 
> > I'm one of the people who need to use lttng-modules on rc kernel.
> 
> If so, please use a git based recipe building the HEAD of the latest released
> stable branch (stable-2.10 currently since 2.11 is in currently in the RC
> stage). If you have problem, report them on our mailing list [1] or our bug
> tracker [2]. We have extensive CI jobs for lttng-modules against the vanilla
> kernel [3] and other usual suspects [4]. We normally catch those problems
> quite quickly. Keep in mind that in no way should a production image be built
> with a non tagged release.
> 
> As for the oe-core recipe, please send us a quick email to let us know, patch
> level releases are cheap. Keep in mind that we are chasing a moving target
> here.
> 
> To add to Mathieu statement, not only do we integrate support for newer kernels into
> the current stable branch but also in all the supported stable branch when
> possible. The supported stable release are normally the 3 latest minor-level releases.

3 -> 2 latest release.

> Currently this set is : 2.8, 2.9, 2.10 .

Slight correction : 2.9, 2.10

> 
> [1] https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> [2] https://bugs.lttng.org/
> [3] An example of such job running: https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_master_build-vanilla/648/console
>     This job validate that lttng-modules master builds against the following vanilla kernel tags. We have
>     similar jobs for master, stable 2.11, stable 2.10, stable 2.9, stable 2.10 lttng-modules branch.
>       v3.0.101
>       v3.1.10
>       v3.2.102
>       v3.3.8
>       v3.4.113
>       v3.5.7
>       v3.6.11
>       v3.7.10
>       v3.8.13
>       v3.9.11
>       v3.10.108
>       v3.11.10
>       v3.12.74
>       v3.13.11
>       v3.14.79
>       v3.15.10
>       v3.16.68
>       v3.17.8
>       v3.18.140
>       v3.19.8
>       v4.0.9
>       v4.1.52
>       v4.2.8
>       v4.3.6
>       v4.4.181
>       v4.5.7
>       v4.6.7
>       v4.7.10
>       v4.8.17
>       v4.9.181
>       v4.10.17
>       v4.11.12
>       v4.12.14
>       v4.13.16
>       v4.14.125
>       v4.15.18
>       v4.16.18
>       v4.17.19
>       v4.18.20
>       v4.19.50
>       v4.20.17
>       v5.0.21
>       v5.1.9
>       v5.2-rc4
> [4] https://ci.lttng.org/view/LTTng-modules/
> 
> -- 
> Jonathan Rajotte-Julien
> EfficiOS

-- 
Jonathan Rajotte-Julien
EfficiOS
-- 

Re: [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1

[He Zhe]

On 6/12/19 10:52 PM, Jonathan Rajotte-Julien wrote:
> Hi,
>
>>> Please don't base distributions on -rc tags. They are not meant for this.
>>>
>>> We always integrate support for newer kernel versions instrumentation back
>>> into our current stable release. So as soon as 5.2 final comes out, we will
>>> release a 2.10.x version including support for it in lttng-modules.
>> I'm one of the people who need to use lttng-modules on rc kernel.
> If so, please use a git based recipe building the HEAD of the latest released
> stable branch (stable-2.10 currently since 2.11 is in currently in the RC
> stage). If you have problem, report them on our mailing list [1] or our bug
> tracker [2]. We have extensive CI jobs for lttng-modules against the vanilla
> kernel [3] and other usual suspects [4]. We normally catch those problems
> quite quickly. Keep in mind that in no way should a production image be built
> with a non tagged release.
>
> As for the oe-core recipe, please send us a quick email to let us know, patch
> level releases are cheap. Keep in mind that we are chasing a moving target
> here.
>
> To add to Mathieu statement, not only do we integrate support for newer kernels into
> the current stable branch but also in all the supported stable branch when
> possible. The supported stable release are normally the 3 latest minor-level releases.
> Currently this set is : 2.8, 2.9, 2.10 .
>
> [1] https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> [2] https://bugs.lttng.org/
> [3] An example of such job running: https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_master_build-vanilla/648/console
>     This job validate that lttng-modules master builds against the following vanilla kernel tags. We have
>     similar jobs for master, stable 2.11, stable 2.10, stable 2.9, stable 2.10 lttng-modules branch.
>       v3.0.101
>       v3.1.10
>       v3.2.102
>       v3.3.8
>       v3.4.113
>       v3.5.7
>       v3.6.11
>       v3.7.10
>       v3.8.13
>       v3.9.11
>       v3.10.108
>       v3.11.10
>       v3.12.74
>       v3.13.11
>       v3.14.79
>       v3.15.10
>       v3.16.68
>       v3.17.8
>       v3.18.140
>       v3.19.8
>       v4.0.9
>       v4.1.52
>       v4.2.8
>       v4.3.6
>       v4.4.181
>       v4.5.7
>       v4.6.7
>       v4.7.10
>       v4.8.17
>       v4.9.181
>       v4.10.17
>       v4.11.12
>       v4.12.14
>       v4.13.16
>       v4.14.125
>       v4.15.18
>       v4.16.18
>       v4.17.19
>       v4.18.20
>       v4.19.50
>       v4.20.17
>       v5.0.21
>       v5.1.9
>       v5.2-rc4
> [4] https://ci.lttng.org/view/LTTng-modules/

Thanks for your great input.

Zhe

>

--