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. > > 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. -- 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
