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

[He Zhe]

On 6/25/19 4:04 PM, richard.purdie at 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
>>> <richard.purdie at linuxfoundation.org> wrote:
>>>> On Tue, 2019-06-11 at 17:03 +0800, zhe.he at windriver.com wrote:
>>>>> From: He Zhe <zhe.he at 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 at 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?
>>>>
>>>> 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
>
>
>