From: Daiane Angolini <daiane.angolini@freescale.com>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: meta-freescale Mailing List <meta-freescale@yoctoproject.org>
Subject: Re: [meta-fsl-arm PATCH 01/23] fsl-dynamic-packagearch.bbclass: Dynamically set package architecture
Date: Tue, 24 Sep 2013 08:21:12 -0300 [thread overview]
Message-ID: <524175A8.8080509@freescale.com> (raw)
In-Reply-To: <CAP9ODKoscqN1gtP9ZJ3LYPQR92O+upmPUGQfg8o=jO-jNa7L4A@mail.gmail.com>
On 09/23/2013 10:04 PM, Otavio Salvador wrote:
> On Mon, Sep 23, 2013 at 8:04 PM, Eric Bénard <eric@eukrea.com> wrote:
>> H Otavio,
>>
>> Le Mon, 23 Sep 2013 16:55:36 -0300,
>> Otavio Salvador <otavio@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@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
next prev parent reply other threads:[~2013-09-24 11:26 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-23 19:55 [meta-fsl-arm PATCH 00/23] Dynamically choose of package architecture Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 01/23] fsl-dynamic-packagearch.bbclass: Dynamically set " Otavio Salvador
2013-09-23 23:04 ` Eric Bénard
2013-09-24 1:04 ` Otavio Salvador
2013-09-24 11:21 ` Daiane Angolini [this message]
2013-09-24 11:58 ` Otavio Salvador
2013-09-24 17:02 ` Eric Bénard
2013-09-24 17:36 ` Otavio Salvador
2013-09-24 18:16 ` Eric Bénard
2013-09-24 18:26 ` Otavio Salvador
2013-09-24 18:40 ` Eric Bénard
2013-09-23 19:55 ` [meta-fsl-arm PATCH 02/23] xf86-input-evdev: Drop PACKAGE_ARCH override Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 03/23] imx-base.inc: Use 'fsl-dynamic-packagearch' class Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 04/23] mxs-base.inc: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 05/23] qt4: Remove redundant PACKAGE_ARCH setting Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 06/23] qt5: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 07/23] mesa-demos: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 08/23] mesa: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 09/23] amd-gpu-mx51.inc: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 10/23] gpu-viv-bin-mx6q.inc: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 11/23] gpu-viv-g2d.inc: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 12/23] imx-test: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 13/23] imx-lib: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 14/23] fsl-alsa-plugins: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 15/23] gst-fsl-plugin.inc: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 16/23] firmware-imx: Use MACHINE_SUBARCH for PACKAGE_ARCH Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 17/23] libdrm: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 18/23] xf86-video-imxfb-vivante: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 19/23] gst-plugins-gl: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 20/23] gst-plugins-base: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 21/23] libfslcodec.inc: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 22/23] libfslparser.inc: " Otavio Salvador
2013-09-23 19:55 ` [meta-fsl-arm PATCH 23/23] libfslvpuwrap: " Otavio Salvador
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=524175A8.8080509@freescale.com \
--to=daiane.angolini@freescale.com \
--cc=meta-freescale@yoctoproject.org \
--cc=otavio@ossystems.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.