[OE-core] [PATCH 1/1] linux-yocto/3.4: v3.4.10 and uprobes/kprobes configuration updates

Tue Sep 11 19:40:03 UTC 2012

On 12-09-11 09:33 AM, Martin Jansa wrote:
> On Tue, Sep 11, 2012 at 09:27:50AM -0400, Bruce Ashfield wrote:
>> On 12-09-11 08:37 AM, Martin Jansa wrote:
>>> On Tue, Sep 11, 2012 at 08:31:42AM -0400, Bruce Ashfield wrote:
>>>> On 12-09-11 02:59 AM, Martin Jansa wrote:
>>>>> On Mon, Sep 10, 2012 at 8:11 PM, Bruce Ashfield
>>>>> <bruce.ashfield at windriver.com>    wrote:
>>>>>> Updating to 3.4.10 which has been soaking for a bit now, as well
>>>>>> as picking up the following meta commits from Tom Z:
>>>>>>
>>>>>>      a82db2f meta: have systemtap use kprobes and uprobes feature
>>>>>>      d5d5b80 meta: add kprobes support to ktypes/standard
>>>>>>      b32d373 meta: add kprobes feature
>>>>>>      d40ed99 meta: have uprobe feature use uprobe.cfg
>>>>>>      a69d1db meta: add uprobe.cfg
>>>>>>
>>>>>> Signed-off-by: Bruce Ashfield<bruce.ashfield at windriver.com>
>>>>>> ---
>>>>>>     meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |    8 ++++----
>>>>>>     meta/recipes-kernel/linux/linux-yocto_3.4.bb    |   16 ++++++++--------
>>>>>>     2 files changed, 12 insertions(+), 12 deletions(-)
>>>>>>
>>>>>> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
>>>>>> index b2620ea..3b36378 100644
>>>>>> --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
>>>>>> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
>>>>>> @@ -3,14 +3,14 @@ require recipes-kernel/linux/linux-yocto.inc
>>>>>>     KBRANCH = "standard/preempt-rt/base"
>>>>>>     KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
>>>>>>
>>>>>> -LINUX_VERSION ?= "3.4.9"
>>>>>> +LINUX_VERSION ?= "3.4.10"
>>>>>>     LINUX_KERNEL_TYPE = "preempt-rt"
>>>>>>
>>>>>>     KMETA = "meta"
>>>>>>
>>>>>> -SRCREV_machine ?= "9032b1e9daf5b4396f939981c3be95f67802d18c"
>>>>>> -SRCREV_machine_qemuppc ?= "08ce190232f89303772b6591ca7daaf2820eb74e"
>>>>>> -SRCREV_meta ?= "463299bc2e533e1bd38b0053ae7b210980f269c3"
>>>>>> +SRCREV_machine ?= "a35693b1287c0e50cdca33a1b95af0ff48b43cd0"
>>>>>> +SRCREV_machine_qemuppc ?= "85a1190530cb5749f5f831670976b163438dc301"
>>>>>> +SRCREV_meta ?= "d9d5fc63d8b38705036e946ea77d971d95de11ad"
>>>>>>
>>>>>>     PR = "${INC_PR}.0"
>>>>>>     PV = "${LINUX_VERSION}+git${SRCPV}"
>>>>>> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
>>>>>> index 06bcb9a..7258cba 100644
>>>>>> --- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
>>>>>> +++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
>>>>>> @@ -3,17 +3,17 @@ require recipes-kernel/linux/linux-yocto.inc
>>>>>>     KBRANCH_DEFAULT = "standard/base"
>>>>>>     KBRANCH = "${KBRANCH_DEFAULT}"
>>>>>>
>>>>>> -SRCREV_machine_qemuarm ?= "84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d"
>>>>>> -SRCREV_machine_qemumips  ?= "ba0e336d4527080233c3c410989d4f351529ee4e"
>>>>>> -SRCREV_machine_qemuppc ?= "e82b8a111430e3820b11f507863c4b8e8734ed8e"
>>>>>> -SRCREV_machine_qemux86 ?= "0985844fa6235422c67ef269952fa4e765f252f9"
>>>>>> -SRCREV_machine_qemux86-64 ?= "0985844fa6235422c67ef269952fa4e765f252f9"
>>>>>> -SRCREV_machine ?= "0985844fa6235422c67ef269952fa4e765f252f9"
>>>>>> -SRCREV_meta ?= "463299bc2e533e1bd38b0053ae7b210980f269c3"
>>>>>> +SRCREV_machine_qemuarm ?= "b15e7b1e9b58b9863bd87778775f86cd8d8880ea"
>>>>>> +SRCREV_machine_qemumips  ?= "8d5b98f263b5119af2dc30223f311be17173bab9"
>>>>>> +SRCREV_machine_qemuppc ?= "b9a720ca38d298ed457f37d099c85771f9164b19"
>>>>>> +SRCREV_machine_qemux86 ?= "46d8c757b3be1953f30d6745505d24436e2d6844"
>>>>>> +SRCREV_machine_qemux86-64 ?= "46d8c757b3be1953f30d6745505d24436e2d6844"
>>>>>> +SRCREV_machine ?= "46d8c757b3be1953f30d6745505d24436e2d6844"
>>>>>> +SRCREV_meta ?= "a82db2f0fc3ceebf3cb47e9dd05e4856ff9966ab"
>>>>>
>>>>> Doesn't different SRCREV_machine for each MACHINE cause LOCALCOUNT in
>>>>> SRCPV incrementing on each MACHINE switch?
>>>>>
>>>>> They are stored under same key:
>>>>> sqlite>    select * from BB_URI_LOCALCOUNT where key like '%linux-yocto-3.4%';
>>>>> git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_rev|84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d
>>>>> git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_count|16
>>>>> git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
>>>>> git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_count|9
>>>>> git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_rev|19f7e43b54aef08d58135ed2a897d77b624b320a
>>>>> git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_count|7
>>>>> git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_rev|9032b1e9daf5b4396f939981c3be95f67802d18c
>>>>> git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_count|10
>>>>> git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
>>>>> git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_count|8
>>>>>
>>>>> So I guess if you build linux-yocto-3.4 for qemuarm, qemux86-64, then
>>>>> switch back to qemuarm you'll see linux-yocto built again, same
>>>>> source, but different SRCPV (LOCALCOUNT).
>>>>
>>>> That does look to be the case, and it matches what I've observed
>>>> over time. I'm not sure of an alternative at the moment, since the
>>>> fetcher is such a cranky beast with respect to fetching changes to
>>>> the right machine branches.
>>>
>>> Why not remove it from SRCREV_FORMAT, keep only meta SRCPV and just bump
>>> PR when SRCREV of some machine kbranch is changed?
>>
>> I like the sound of it, but as far as I know, wouldn't that fix the
>> package revision, but cause the fetcher problems ? I've added Richard
>> to the cc, since I'm not sure what the current status of the fetcher
>> is in this regard.
>>
>> If I don't bump the SRCREV for the machines, and just bump the PR,
>> there's nothing in place to trigger the fetcher when only machine
>> changes have been made to one of the branches, and conversely there's
>
> PR bump will trigger recipe rebuild and while rebuilding fetcher will
> download revision set by SRCREV, why shoudln't it?

It definitely should .. but the fetcher has proven me wrong before.

>
> Only disadvantage I see is that PR bump is "global" so all machines get
> rebuilt when you bump it only because of one machine changing SRCREV,
> but that's still better then rebuilding without any change in sources at
> all.

.. and I staring at this a bit, I think I'm catching up (not enough
coffee this morning and too little sleep).

I think I mentally mangled this to include dropping the machine
SRCREV from the recipe, where you are talking about dropping the
from the PV and SRCREV_FORMAT.

If in fact the fetcher will update the machine SRCREV on a PR bump,
then this should work.

But one stupid question, if machine has been removed from the SRCREV
format, is the fetcher really going to trigger ? A quick look at the
fetcher code doesn't leave me convinced ...

Bruce

>
> Cheers,
>
>> no explicit value set to inhibit a machine's SRCREV when you don't
>> want the end of the branch to be built (I always build the end, but
>> other layers inhibit SRCREV frequently to throttle their updates).
>>
>> If there's a better way that keeps the rebuilds to a minimum, but
>> doesn't break the fetcher and those other use cases .. I'm more than
>> happy to switch to it :)
>>
>> Bruce
>>
>>>
>>> Current SRCREV_FORMAT doesn't show which branch it was so it doesn't
>>> make it much worse to find what sources were used to build.
>>>
>>> Cheers,
>>>
>>
>