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. For me it looks like a temporary fix being assumed mainline. Daiane > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.br http://code.ossystems.com.br > Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 > -- > _______________________________________________ > meta-freescale mailing list > [email protected] > https://lists.yoctoproject.org/listinfo/meta-freescale -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
