[OE-core] [PATCH 2/2] kernel: Add optional patch_xenomai task

Bruce Ashfield bruce.ashfield at gmail.com
Sun Jan 7 17:55:21 UTC 2018


On Sun, Jan 7, 2018 at 12:53 PM, Marek Vasut <marex at denx.de> wrote:
> On 01/07/2018 05:42 PM, Bruce Ashfield wrote:
>> On Sun, Jan 7, 2018 at 11:38 AM, Marek Vasut <marex at denx.de> wrote:
>>> On 01/07/2018 05:37 PM, Bruce Ashfield wrote:
>>>> On Sun, Jan 7, 2018 at 11:19 AM, Marek Vasut <marex at denx.de> wrote:
>>>>> Add additional task, do_patch_xenomai, inserted between do_patch and
>>>>> do_configure tasks. This task applies the cobalt patch to the kernel
>>>>> sources for a specific machine. This is disabled by default, so use
>>>>> PACKAGECONFIG[xenomai] of the kernel package to enable the patching.
>>>>>
>>>>> You will also need a kernel recipe for a kernel version with ipipe
>>>>> patch applied.
>>>>
>>>> This doesn't make any sense to me.
>>>>
>>>> Why on earth would this be in kernel.bbclass ? and part of a xenomai
>>>> recipe ?
>>> Do you have a better suggestion how to make this easily available for
>>> every kernel recipe ?
>>
>> There's no need to make it available for every kernel recipe. If someone
>> wants to build xenomai, they need to have a specific kernel recipe and
>> configuration to make it work. By providing that patch and allowing it to
>> be applied to any kernel doesn't mean it will actually work .. so you aren't
>> doing anyone any favours.
>>
>> The same thing could be said for the -rt patch, aufs, etc, any patch could
>> be made available for any kernel, but they aren't, since they will either fail
>> to patch, or won't work at runtime.
> We actually have a -rt patch available in the kernel recipes, so why not
> xenomai patch ?

As a separate recipe, not as something in a common bbclass, which implies
that it applies and works everywhere.

Anyone that is trying to apply -rt against a generic kernel .. is very mistaken.

Bruce

>
> --
> Best regards,
> Marek Vasut



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"



More information about the Openembedded-core mailing list