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

[Eric Bénard]

Le Tue, 24 Sep 2013 14:36:21 -0300,
Otavio Salvador <otavio at ossystems.com.br> a écrit :

> On Tue, Sep 24, 2013 at 2:02 PM, Eric Bénard <eric at eukrea.com> wrote:
> > Le Mon, 23 Sep 2013 22:04:41 -0300,
> > Otavio Salvador <otavio at ossystems.com.br> a écrit :
> >
> >> 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.
> >
> > how many recipes are concerned by these 75 packages ?
> 
> gpu-viv, xserver-xorg and more ... (full list for fsl-image-gui - 235
> rpm packages - attached).
> 
> >> 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
> >
> > do you have an example ?
> 
> Sure; for example a weston package (which we don't have a bbappend)
> will have the package architecture set to the mx6 subarch as it
> depends on the gpu libraries. This also works for customer recipes and
> other layers.
> 
> Otherwise we'd need to include bbappend files for all those recipes.
> 
> >> * 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
> >
> > but in the present patchset you don't remove any bbappend !
> 
> Yes and not all where being done right. We had most as machine
> specific which where wrong.
> 
OK that seems fine.

Do you have an idea of the cost on the build/parse time ?

> > What is the cost on the build/parse time to have this code running
> > dynamicaly ?
> >
> > While at it : why does qt4 depends on virtual/kernel ?
> > That's quite annoying as it seems qt gets rebuilt everytime we make a
> > change to the kernel.
> 
> It uses kernel headers and do syscalls for mxcfb. I am open for an
> advise how to make this better.
> 
maybe we could include the linux/mxcfb.h in the patch as these 2
ioctls and the 2 struct have little chance to change ?

Eric