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

[Daiane Angolini]

On Tue, Apr 28, 2015 at 1:14 AM, Nikolay Dimitrov <picmaster at mail.bg> wrote:
> 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.
>>

I have been thinking about this topic, and I think I have it
elaborated in my mind already.

My problem is not exactly having another linux provider. My problem is
having an implicit fork of linux-fslc.

The base argument used by Otavio is that you are the machine
mantainer, you decide which kernel you want to you, and I agree with
it.

However, you are not proposing a new kernel provider. You are
proposing a new abstraction layer between your machine and the
linux-fslc. Or, in other words, an implicit fork of linux-fslc.

If you were looking for upstreaming. You would not propose such thing.
Because, when targeting the upstream, you work upstream.

Otavio proposed a bbappend. An explicit way of forking linux-fslc.

Another way would be a fork. For example, if the goal is to add riot
support on top of linux-imx (3.14), the better way would be a fork of
linux-imx adding a patchset to support riot. In this case (linux-imx)
there is no formal upstreaming process.

linux-fslc is itself a fork of kernel.org. A stash we use for 2 main
goals, keep the needed backport patches while it's been accepted into
kernel.org stable releases and keep the cosmetic patches which does
not make sense for kernel.org (i.e. setting the default sdcard number
for boot, setting the default bootargs, and so on)

Maybe, it makes sense for riot to have a fork, being it based on
linux-imx, or linux-fslc or linux-daiane or kernel.org.
In this case, the machine mantainer is the one to decide what to do,
and what to upstream to kernel.org. However, I want to emphasize that
keeping a fork is not an easy task.

For me, only reverting a patch that has been debugged is not a strong
enough argument to have a fork (and all the work behind it). But I
cannot see your future plans for the board.

I have had access to the riot board for really few days, I've taken
advance of each of them to get this board upstreamed asap, because I
knew someone would need and like it. Unfortunately, I don't have the
hardware anymore, so I cannot help the way I would like.

I really hope meta-fsl-arm-extra machine recipe to be only a enabler
for the kernel development focusing on this board.

Regards,
Daiane

>
> OK.
>
> Regards,
> Nikolay