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 <[email protected]> wrote:
Add dedicated RIoTboard kernel recipe for easier maintenance and patch
cherry-picking.
Signed-off-by: Nikolay Dimitrov <[email protected]>
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
--
_______________________________________________
meta-freescale mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-freescale
