[OE-core] How to patch yocto kernel

[Khem Raj]

On Sun, May 1, 2011 at 10:31 PM, Bruce Ashfield
<bruce.ashfield at gmail.com> wrote:
> On Sun, May 1, 2011 at 11:56 PM, Khem Raj <raj.khem at gmail.com> wrote:
>> On Sun, May 1, 2011 at 7:40 PM, Bruce Ashfield <bruce.ashfield at gmail.com> wrote:
>>> On Sun, May 1, 2011 at 9:14 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>>> Hi
>>>>
>>>> I am trying to test this patch
>>>>
>>>> http://uclibc.org/~kraj/perf-tool-Fix-gcc-4.6.0-issues.patch
>>>>
>>>> to fix the build using gcc 4.6.0 but the kernel patching for yocto is
>>>> not as usual as other recipes
>>>> since it uses entire set of tooling around it.
>>>>
>>>> I tried to look around for documentation and few references I found
>>>>
>>>> https://wiki.pokylinux.org/wiki/Wind_River_Kernel
>>>>
>>>> discourages putting patches in metadata. and in another document it
>>>> says it uses git to do patching but does not explain how.
>>>>
>>>> So if someone can explain in simple terms how to patch a linux-yocto
>>>> would be really helpful from a
>>>> developer POV or any documentation will be helpful.
>>>>
>>>> How do people develop/test patches on linux-yocto I understand
>>>> eventually they are desired to be part
>>>> of linux-yocto git but that comes after they are tried and tested locally
>>>>
>>>> I would have preferred to have the usual SRC_URI patching atleast for
>>>> local testing. As of now
>>>> it seems not to use normal OE recipe procedures.
>>>
>>> Are you actually not  seeing this work ? I put in place compatibility
>>> with existing patching via the SRC_URI for just this reason. A patch
>>> specified in the SRC_URI will be picked up by the tools and applied
>>> to the end of the BSP branch during the patching phase.
>>>
>>
>> if it worked. I would not be writing this email :)
>
> :) you never know, I didn't see your error message so I didn't want
> to presume.
>
> But I spoke too soon earlier, I had a bbappend in my layers that
> meant I was modifying the wrong SRC_URI to have your patch
> applied.
>
> When I modified the right SRC_URI like so:
>
> +SRC_URI = "git://git.yoctoproject.org/linux-yocto-2.6.37;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta\
> +           file://perf-tool-Fix-gcc-4.6.0-issues.patch"
>
> (i.e. the obvious way)
>
> I see the patch applied to the end of my BSP branch:
>
>> git branch
>  master
>  meta
>  yocto/base
>  yocto/eg20t
>  yocto/emgd
>  yocto/gma500
>  yocto/standard/arm-versatile-926ejs
>  yocto/standard/base
>  yocto/standard/beagleboard
>  yocto/standard/common-pc-64/base
>  yocto/standard/common-pc-64/jasperforest
>  yocto/standard/common-pc-64/sugarbay
>  yocto/standard/common-pc/atom-pc
> * yocto/standard/common-pc/base
>
> commit 2500f7dc4d6c0d8b2f5ddad6369ee4541456533a
> Author: Kyle McMartin <kyle at mcmartin.ca>
> Date:   Mon May 2 01:26:49 2011 -0400
>
>    commit fb7d0b3cefb80a105f7fd26bbc62e0cbf9192822 upstream.
>
>    GCC 4.6.0 in Fedora rawhide turned up some compile errors in tools/perf
>    due to the -Werror=unused-but-set-variable flag.
>
>    I've gone through and annotated some of the assignments that had side
>    effects (ie: return value from a function) with the __used annotation,
>    and in some cases, just removed unused code.
>
>    In a few cases, we were assigning something useful, but not using it in
>    later parts of the function.
>
>    kyle at dreadnought:~/src% gcc --version
>    gcc (GCC) 4.6.0 20110122 (Red Hat 4.6.0-0.3)
>
>    Cc: Ingo Molnar <mingo at redhat.com>
>    LKML-Reference: <20110124161304.GK27353 at bombadil.infradead.org>
>    Signed-off-by: Kyle McMartin <kyle at redhat.com>
>    [ committer note: Fixed up the annotation fixes, as that code
> moved recently ]
>    Signed-off-by: Arnaldo Carvalho de Melo <acme at redhat.com>
>    [Backported to 2.6.38.2 by deleting unused but set variables]
>    Signed-off-by: Thomas Meyer <thomas at m3y3r.de>
>    Signed-off-by: Greg Kroah-Hartman <gregkh at suse.de>
>    [Backported to linux-yocto kernel git version]
>    Signed-off-by: Khem Raj <raj.khem at gmail.com>
>
> I did modify the patch format slightly, since git am needs to be able to
> grok the patch for it to apply.
>
> Did you get any sort of error message when your patch didn't apply ?
>

yes it would not apply the patch and instead complained it could not
checkout a branch because tree was dirty
I dont have exact message handy. I will see if I can reproduce it

> Cheers,
>
> Bruce
>
>>
>>> It has definitely worked during all the development cycles, so if you
>>> are seeing it not work, it's a bug and I'll fix it.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>> Thanks
>>>> -Khem
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core at lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>>
>>>
>>>
>>>
>>> --
>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>> thee at its end"
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core at lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>