Le Tue, 24 Sep 2013 14:36:21 -0300, Otavio Salvador <[email protected]> a écrit :
> On Tue, Sep 24, 2013 at 2:02 PM, Eric Bénard <[email protected]> wrote: > > Le Mon, 23 Sep 2013 22:04:41 -0300, > > Otavio Salvador <[email protected]> a écrit : > > > >> On Mon, Sep 23, 2013 at 8:04 PM, Eric Bénard <[email protected]> wrote: > >> > H Otavio, > >> > > >> > Le Mon, 23 Sep 2013 16:55:36 -0300, > >> > Otavio Salvador <[email protected]> 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 <[email protected]> > >> ... > >> > 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 _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
