[OE-core] [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

Dmitry Eremin-Solenikov dbaryshkov at gmail.com
Wed Sep 28 18:50:39 UTC 2011


On 9/28/11, Koen Kooi <koen at dominion.thruhere.net> wrote:
>
>
> Op 28 sep. 2011 om 09:54 heeft Richard Purdie
> <richard.purdie at linuxfoundation.org> het volgende geschreven:
>
>> On Tue, 2011-09-27 at 18:40 -0500, Koen Kooi wrote:
>>>
>>> Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <bruce.ashfield at gmail.com>
>>> het volgende geschreven:
>>>
>>>> On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
>>>> <dbaryshkov at gmail.com> wrote:
>>>>> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present
>>>>> in
>>>>> meta-oe kernel.bbclass. Several machines depend on this functionality.
>>>>
>>>> I don' t have a big problem with this, since the change is obviously
>>>> harmless if it
>>>> doesn't need to be used. But similar to my comment on patch 3/5, is
>>>> there any
>>>> history/technical reasons we can capture here ?
>>>>
>>>> I did a quick search to dig up a bit on this myself, but a summary
>>>> would definitely
>>>> help, since I see that this has a long and sometimes twisting history.
>>>> Is it as
>>>> simple as ?
>>>>
>>>> "A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
>>>> rebuilds for kernel and external modules"
>>>
>>> It is that simple :)
>>
>> I have reservations about this patch given we soon plan to stop needing
>> to bump PR values. This patch is actually a perfect example of how brain
>> dead the current manual PR bumping is and why we need something better.
>> I don't want half the code in the repo to be a mass of PR values which
>> need to be incremented manually under weird and wonderful circumstances
>> which is where the direction things are currently going...
>>
>> I'd like to hold off on this one.
>
> This patch improves the current situation and I don't foresee the autoPR
> code working soon

As another point for this patch: I'd like to ask Koen to drop
kernel.bbclass from
meta-oe. After do_uboot_mkimage this is the only significant difference. And
unfortunately this feature is already used on several machines. Quick
grep return the following results. Koen, could you comment on this?

$ grep MACHINE_KERNEL_PR */{,*/}c* -r
meta-openpandora/conf/machine/include/omap3.inc:MACHINE_KERNEL_PR = "r101"
meta-openpandora/conf/machine/omap3-pandora.conf:MACHINE_KERNEL_PR = "r3"
meta-texasinstruments/conf/machine/include/davinci.inc:MACHINE_KERNEL_PR = "r51"
meta-texasinstruments/conf/machine/include/omap3.inc:MACHINE_KERNEL_PR = "r105"
meta-texasinstruments/conf/machine/include/ti814x.inc:MACHINE_KERNEL_PR = "r1"
meta-texasinstruments/conf/machine/include/ti816x.inc:MACHINE_KERNEL_PR = "r2"
meta-smartphone/meta-nokia/conf/machine/nokia900.conf:MACHINE_KERNEL_PR = "r68"
meta-smartphone/meta-palm/conf/machine/include/palmpre.inc:MACHINE_KERNEL_PR
= "r0"
meta-texasinstruments/recipes-ti/c6accel/ti-c6accel.inc:PR =
"${MACHINE_KERNEL_PR}"
meta-texasinstruments/recipes-ti/codec-engine/ti-codec-engine.inc:PR =
"${MACHINE_KERNEL_PR}"
meta-texasinstruments/recipes-ti/codec-engine/ti-codecs-omap3530_4.00.00.00.bb:PR="${MACHINE_KERNEL_PR}"
openembedded-core/meta/classes/kernel.bbclass:    machine_kernel_pr =
bb.data.getVar('MACHINE_KERNEL_PR', d, True)



-- 
With best wishes
Dmitry




More information about the Openembedded-core mailing list