[OE-core] How to patch yocto kernel

[Bruce Ashfield]

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 ?

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"