Hi Daiane, Otavio,
On 04/27/2015 07:59 PM, Otavio Salvador wrote:
On Mon, Apr 27, 2015 at 1:54 PM, Daiane Angolini
<[email protected]> wrote:
On Mon, Apr 27, 2015 at 1:26 PM, Otavio Salvador
<[email protected]> wrote:
On Mon, Apr 27, 2015 at 12:27 PM, Nikolay Dimitrov
<[email protected]> wrote:
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"
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
--
_______________________________________________
meta-freescale mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-freescale
