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

[Nikolay Dimitrov]

Hi Daiane, Otavio,

On 04/27/2015 07:59 PM, Otavio Salvador wrote:
> 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.

@Daiane, would you like to elaborate on this?

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

OK.

Regards,
Nikolay