[meta-freescale] [meta-fsl-arm PATCH 01/23] fsl-dynamic-packagearch.bbclass: Dynamically set package architecture

Daiane Angolini daiane.angolini at freescale.com
Tue Sep 24 04:21:12 PDT 2013


On 09/23/2013 10:04 PM, Otavio Salvador wrote:
> On Mon, Sep 23, 2013 at 8:04 PM, Eric Bénard <eric at eukrea.com> wrote:
>> H Otavio,
>>
>> Le Mon, 23 Sep 2013 16:55:36 -0300,
>> Otavio Salvador <otavio at ossystems.com.br> a écrit :
>>
>>> This allow to easy reuse of binary packages among similar SoCs. The
>>> usual use for this is to share SoC specific packages among different
>>> boards. The class can be used to share GPU packages for i.MX53 boards
>>> (as all them share the AMD GPU) and i.MX6 based boards (as all them
>>> share Vivante GPU).
>>>
>>> It inspects the database and identify if the package provides or
>>> depends on one of subarch provided values and if it does, it sets the
>>> PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the
>>> machine specific filter, it sets it to MACHINE_ARCH.
>>>
>>> Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8
>>> Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
> ...
>> what is the time cost of this dynamic setting vs the static one ?
>
> This reduces the amount of packages we build, for example in case of
> core-image-x11 we:
>
> $ ls -l tmp/deploy/rpm/cortexa9hf_vfp_neon_mx6/*.rpm | wc -l
> 75
>
> So we reuse 75 binaries; these would be build otherwise.
>
> Regarding it being dynamically set or statically set it has following benefits:
>
> * correctness: it is easier to ensure the system behaves as expected
> * correctness for non-tracked recipes: new recipes, if depending on
> virtual/kernel or GPU has the right architecture choosen, without a
> .bbappend file for them
> * safeness: non-expert users get a more adequate behavior as the
> complexity of choosing the right architecture is simplified for them
> * easy maintenance: it is easier for me, as maintainer, to maintain a
> code which decides what to do than having hundreds of bbappend files
> for it
>
> I hope it justify it enough.

Could you, please, explain how this is a upstream trend?
(or, in other words, how this is the same thing people are doing for 
mesa in poky)

Consider to include those justification on commit log.

>
> Regards,
>


-- 
Daiane




More information about the meta-freescale mailing list