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

2019-06-25 Thread He Zhe 



On 6/25/19 4:04 PM, richard.pur...@linuxfoundation.org wrote:
> On Tue, 2019-06-25 at 15:59 +0800, He Zhe wrote:
>> On 6/12/19 6:57 AM, Bruce Ashfield wrote:
>>> On Tue, Jun 11, 2019 at 6:50 PM Richard Purdie
>>>  wrote:
 On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
> From: He Zhe 
>
> 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 
> ---
> 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?

 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?

 Would you be willing to try/submit such a git recipe?
>>> This makes sense to me as well, since I'm one of the folks that
>>> runs
>>> into this issue the most. In fact, I've been carrying a local _git
>>> version of the lttng recipe for over a year, since I didn't feel
>>> like
>>> getting into the _git versus release tarballs debate. This solution
>>> should avoid that debate and keep all the different versions of
>>> kernels moving along.
>> Hi Bruce and Richard,
>>
>> BTW, how about using git for all cases so that people don't have to
>> maintain a
>> tarball locally? Though I don't have the background knowledge of that
>> git vs
>> tarball debate mentioned above.
> The overhead of tarball releases is much lower than git trees for each
> piece of software so I'd prefer to have tarball recipes where we can,
> it does lead to faster builds.

Got it, thanks.

Zhe

>
> Cheers,
>
> Richard
>
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-25 Thread richard . purdie 
On Tue, 2019-06-25 at 15:59 +0800, He Zhe wrote:
> 
> On 6/12/19 6:57 AM, Bruce Ashfield wrote:
> > On Tue, Jun 11, 2019 at 6:50 PM Richard Purdie
> >  wrote:
> > > On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
> > > > From: He Zhe 
> > > > 
> > > > 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 
> > > > ---
> > > > 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?
> > > 
> > > 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?
> > > 
> > > Would you be willing to try/submit such a git recipe?
> > This makes sense to me as well, since I'm one of the folks that
> > runs
> > into this issue the most. In fact, I've been carrying a local _git
> > version of the lttng recipe for over a year, since I didn't feel
> > like
> > getting into the _git versus release tarballs debate. This solution
> > should avoid that debate and keep all the different versions of
> > kernels moving along.
> 
> Hi Bruce and Richard,
> 
> BTW, how about using git for all cases so that people don't have to
> maintain a
> tarball locally? Though I don't have the background knowledge of that
> git vs
> tarball debate mentioned above.

The overhead of tarball releases is much lower than git trees for each
piece of software so I'd prefer to have tarball recipes where we can,
it does lead to faster builds.

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-25 Thread He Zhe 



On 6/12/19 6:57 AM, Bruce Ashfield wrote:
> On Tue, Jun 11, 2019 at 6:50 PM Richard Purdie
>  wrote:
>> On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
>>> From: He Zhe 
>>>
>>> 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 
>>> ---
>>> 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?
>>
>> 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?
>>
>> Would you be willing to try/submit such a git recipe?
> This makes sense to me as well, since I'm one of the folks that runs
> into this issue the most. In fact, I've been carrying a local _git
> version of the lttng recipe for over a year, since I didn't feel like
> getting into the _git versus release tarballs debate. This solution
> should avoid that debate and keep all the different versions of
> kernels moving along.

Hi Bruce and Richard,

BTW, how about using git for all cases so that people don't have to maintain a
tarball locally? Though I don't have the background knowledge of that git vs
tarball debate mentioned above.

Zhe

>
> Bruce
>
>> Cheers,
>>
>> Richard
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-13 Thread 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

>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-12 Thread 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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-12 Thread 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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-12 Thread Mathieu Desnoyers 
- On Jun 12, 2019, at 3:27 PM, Adrian Bunk b...@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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-12 Thread 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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-12 Thread He Zhe 



On 6/12/19 7:29 PM, Mathieu Desnoyers wrote:
> - On Jun 12, 2019, at 1:10 PM, zhe he zhe...@windriver.com wrote:
>
>> On 6/12/19 6:58 PM, Mathieu Desnoyers wrote:
>>> - On Jun 12, 2019, at 12:51 PM, Adrian Bunk b...@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...@windriver.com wrote:
>> From: He Zhe 
>>
>> 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 
>> ---
>> 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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

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

> On 6/12/19 6:58 PM, Mathieu Desnoyers wrote:
>> - On Jun 12, 2019, at 12:51 PM, Adrian Bunk b...@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...@windriver.com wrote:
> From: He Zhe 
>
> 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 
> ---
> 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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-12 Thread He Zhe 



On 6/12/19 6:58 PM, Mathieu Desnoyers wrote:
> - On Jun 12, 2019, at 12:51 PM, Adrian Bunk b...@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...@windriver.com wrote:
 From: He Zhe 

 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 
 ---
 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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-12 Thread Mathieu Desnoyers 
- On Jun 12, 2019, at 12:51 PM, Adrian Bunk b...@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...@windriver.com wrote:
>> > From: He Zhe 
>> > 
>> > 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 
>> > ---
>> > 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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-12 Thread Adrian Bunk 
On Tue, Jun 11, 2019 at 11:49:34PM +0100, Richard Purdie wrote:
> On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
> > From: He Zhe 
> > 
> > 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 
> > ---
> > 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.

> 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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-12 Thread He Zhe 



On 6/12/19 6:49 AM, Richard Purdie wrote:
> On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>> 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 
>> ---
>> 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?
>
> 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?
>
> Would you be willing to try/submit such a git recipe?

OK. I'll send a git recipe.

Regards,
Zhe

>
> Cheers,
>
> Richard
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-11 Thread Bruce Ashfield 
On Tue, Jun 11, 2019 at 6:50 PM Richard Purdie
 wrote:
>
> On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
> > From: He Zhe 
> >
> > 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 
> > ---
> > 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?
>
> 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?
>
> Would you be willing to try/submit such a git recipe?

This makes sense to me as well, since I'm one of the folks that runs
into this issue the most. In fact, I've been carrying a local _git
version of the lttng recipe for over a year, since I didn't feel like
getting into the _git versus release tarballs debate. This solution
should avoid that debate and keep all the different versions of
kernels moving along.

Bruce

>
> Cheers,
>
> Richard
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-11 Thread Richard Purdie 
On Tue, 2019-06-11 at 17:03 +0800, zhe...@windriver.com wrote:
> From: He Zhe 
> 
> 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 
> ---
> 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?

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?

Would you be willing to try/submit such a git recipe?

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

2019-06-11 Thread zhe.he 
From: He Zhe 

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 
---
v2: Correct a typo in SOB for 0001*.patch

 ...ove-wrapper-definitions-for-obsolete-RCU..patch |  47 
 ...ix-timer-trace-Improve-timer-tracing-v5.2.patch |  80 +++
 .../0003-Fix-pipe-stop-using-can_merge-v5.1.patch  |  42 
 ...ix-mm-create-the-new-vm_fault_t-type-v5.1.patch |  65 ++
 ...an-drop-may_writepage-and-classzone_idx-f.patch |  92 
 ...only-read-from-dev-random-after-its-pool-.patch |  76 ++
 ...start-and-number-from-syscall_get_argumen.patch | 259 +
 meta/recipes-kernel/lttng/lttng-modules_2.10.9.bb  |   7 +
 8 files changed, 668 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-Fix-rcu-Remove-wrapper-definitions-for-obsolete-RCU..patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0002-fix-timer-trace-Improve-timer-tracing-v5.2.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0003-Fix-pipe-stop-using-can_merge-v5.1.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0004-Fix-mm-create-the-new-vm_fault_t-type-v5.1.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0005-fix-mm-vmscan-drop-may_writepage-and-classzone_idx-f.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0006-fix-random-only-read-from-dev-random-after-its-pool-.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0007-Fix-Remove-start-and-number-from-syscall_get_argumen.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/0001-Fix-rcu-Remove-wrapper-definitions-for-obsolete-RCU..patch
 
b/meta/recipes-kernel/lttng/lttng-modules/0001-Fix-rcu-Remove-wrapper-definitions-for-obsolete-RCU..patch
new file mode 100644
index 000..de572a9
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-modules/0001-Fix-rcu-Remove-wrapper-definitions-for-obsolete-RCU..patch
@@ -0,0 +1,47 @@
+From 92da05ce1f73488a57e7fd79e9c03113cefdb76f Mon Sep 17 00:00:00 2001
+From: Michael Jeanson 
+Date: Mon, 18 Mar 2019 16:20:33 -0400
+Subject: [PATCH] Fix: rcu: Remove wrapper definitions for obsolete RCU...
+ (v5.1)
+
+See upstream commit :
+
+commit 6ba7d681aca22e53385bdb35b1d7662e61905760
+Author: Paul E. McKenney 
+Date:   Wed Jan 9 15:22:03 2019 -0800
+
+rcu: Remove wrapper definitions for obsolete RCU update functions
+
+None of synchronize_rcu_bh, synchronize_rcu_bh_expedited, call_rcu_bh,
+rcu_barrier_bh, synchronize_sched, synchronize_sched_expedited,
+call_rcu_sched, rcu_barrier_sched, get_state_synchronize_sched, and
+cond_synchronize_sched are actually used.  This commit therefore removes
+their trivial wrapper-function definitions.
+
+Signed-off-by: Mathieu Desnoyers 
+Upstream-Status: Backport
+Signed-off-by: He Zhe 
+---
+ lttng-events.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/lttng-events.c b/lttng-events.c
+index 566080a..f4206c5 100644
+--- a/lttng-events.c
 b/lttng-events.c
+@@ -75,7 +75,12 @@ int _lttng_field_statedump(struct lttng_session *session,
+ 
+ void synchronize_trace(void)
+ {
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,1,0))
++  synchronize_rcu();
++#else
+   synchronize_sched();
++#endif
++
+ #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,4,0))
+ #ifdef CONFIG_PREEMPT_RT_FULL
+   synchronize_rcu();
+-- 
+2.7.4
+
diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/0002-fix-timer-trace-Improve-timer-tracing-v5.2.patch
 
b/meta/recipes-kernel/lttng/lttng-modules/0002-fix-timer-trace-Improve-timer-tracing-v5.2.patch
new file mode 100644
index 000..e782ee0
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-modules/0002-fix-timer-trace-Improve-timer-tracing-v5.2.patch
@@ -0,0 +1,80 @@
+From d88e2fe5c3ea0d2c3055fba824be17223c418854 Mon Sep 17 00:00:00 2001
+From: Michael Jeanson 
+Date: Tue, 21 May 2019 16:33:10 -0400
+Subject: [PATCH] fix: timer/trace: Improve timer tracing (v5.2)
+
+See upstream commit:
+
+  commit f28d3d5346e97e60c81f933ac89ccf015430e5cf
+  Author: Anna-Maria Gleixner 
+  Date:   Thu Mar 21 13:09:21 2019 +0100
+
+timer/trace: Improve timer tracing
+
+Timers are added to the timer wheel off by one. This is required in
+case a timer is queued directly before incrementing jiffies to prevent
+early timer expiry.
+
+When reading a timer trace and relying only on the expiry time of the timer
+in the timer_start trace point and on the now in the timer_expiry_entry
+trace point, it seems that the timer fires late. With the current
+timer_expiry_entry trace point information only now=jiffies is printed but
+not the value of base->clk. This makes it impossible to draw a conclusion
+to the index of base->clk and makes it impossible to examine timer problems
+without additional trace points.
+
+Therefore add the base->clk value to the timer_expire_entry trace
+