[meta-freescale] [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe

[Otavio Salvador]

On Mon, Apr 27, 2015 at 1:54 PM, Daiane Angolini <daiane.list at gmail.com> wrote:
> On Mon, Apr 27, 2015 at 1:26 PM, Otavio Salvador
> <otavio at ossystems.com.br> wrote:
>> On Mon, Apr 27, 2015 at 12:27 PM, Nikolay Dimitrov <picmaster at mail.bg> wrote:
>>> On 04/27/2015 02:40 PM, Otavio Salvador wrote:
>>>>
>>>> Hello Nikolay,
>>>>
>>>> On Mon, Apr 27, 2015 at 1:35 AM, Nikolay Dimitrov <picmaster at mail.bg>
>>>> wrote:
>>>>>
>>>>> Add dedicated RIoTboard kernel recipe for easier maintenance and patch
>>>>> cherry-picking.
>>>>>
>>>>> Signed-off-by: Nikolay Dimitrov <picmaster at mail.bg>
>>>>
>>>>
>>>> I want to check with you if you really want to have a dedicated
>>>> recipe. For bugfixes (as now) you can use a bbappend as a temporary
>>>> solution and, at end of the day, easy to remove once this is fixed in
>>>> the kernel.
>>>>
>>>> Please let me know your thoughts...
>>>
>>>
>>> Do you mean something like this (bbappend in meta-fsl-arm-extra)?
>>>
>>> diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>> b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>> new file mode 100644
>>> index 0000000..d7a4e72
>>> --- /dev/null
>>> +++ b/recipes-kernel/linux/linux-fslc_4.0.bbappend
>>> @@ -0,0 +1,3 @@
>>> +FILESEXTRAPATHS_append := ":${THISDIR}/${PN}"
>>> +
>>> +SRC_URI_imx6dl-riotboard = "file://riotboard-specific.patch"
>>
>> Yes.
>>
>>> Well, imho the difference between bbappending and having a separate
>>> recipe is that the bbappending mechanism is retro-reactive - I can
>>> bbappend patches to linux-fslc but in the meantime the board support
>>> will be broken.
>>>
>>> Maintaining a separate kernel recipe for riotboard is a proactive way,
>>> imho. When linux-fslc updates are happening, they won't immediately
>>> break the riotboard, and after I test the updates I can update SRC_REV
>>> to point it to a specific working commit, or as in my case point
>>> SRC_REV to the latest commit and revert just one specific patch. The
>>> advantage is that all the time the board support will be working.
>>>
>>> This was my motivation for the patch. Please tell me if there are any
>>> drawback of having a separate board kernel recipe.
>>
>> Maintenance burden.
>>
>> Your thought is right but what should have been done was people to
>> report this issue when we included 4.0 recipe.
>>
>> For now a bbappend would work as a band-aid while the real fix is
>> being cooked.  I usually do not do design for the exception and I
>> believe linux-fslc once fixed will be kept working for the board.
>>
>> This is really up to you but I think a boot test every time we prepare
>> a bump linux-fslc would be enough to iron out the need of a specific
>> recipe.
>
> Otavio, I really don't like to see more and more linux providers on
> top of linux-fslc. We already have too much linux providers.
>
> For me it looks like a temporary fix being assumed mainline.

So the bbappend for a workaround while linux-fslc is proper fixed
seems to be the way to go. I second your view I also prefer to not
have many kernel providers except if there are real reasons for it. In
Linux mainline case I see none.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750