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

[Nikolay Dimitrov]

Hi Otavio,

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"

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.

Regards,
Nikolay