From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 35F32E015E1 for ; Tue, 24 Sep 2013 04:26:03 -0700 (PDT) Received: from mail193-db8-R.bigfish.com (10.174.8.250) by DB8EHSOBE003.bigfish.com (10.174.4.66) with Microsoft SMTP Server id 14.1.225.22; Tue, 24 Sep 2013 11:26:01 +0000 Received: from mail193-db8 (localhost [127.0.0.1]) by mail193-db8-R.bigfish.com (Postfix) with ESMTP id D9D62C00199; Tue, 24 Sep 2013 11:26:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI; H:mail.freescale.net; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzbb2dI98dI9371Ic89bh1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097h8275bhz2dh2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1f5fh1fe8h1ff5h209eh1155h) Received: from mail193-db8 (localhost.localdomain [127.0.0.1]) by mail193-db8 (MessageSwitch) id 1380021960286775_6717; Tue, 24 Sep 2013 11:26:00 +0000 (UTC) Received: from DB8EHSMHS005.bigfish.com (unknown [10.174.8.239]) by mail193-db8.bigfish.com (Postfix) with ESMTP id 3773A880064; Tue, 24 Sep 2013 11:26:00 +0000 (UTC) Received: from mail.freescale.net (70.37.183.190) by DB8EHSMHS005.bigfish.com (10.174.4.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 24 Sep 2013 11:26:00 +0000 Received: from tx30smr01.am.freescale.net (10.81.153.31) by 039-SN1MMR1-005.039d.mgd.msft.net (10.84.1.17) with Microsoft SMTP Server (TLS) id 14.3.158.2; Tue, 24 Sep 2013 11:25:56 +0000 Received: from [10.29.244.63] ([10.29.244.63]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id r8OBPcwP017926; Tue, 24 Sep 2013 04:25:55 -0700 Message-ID: <524175A8.8080509@freescale.com> Date: Tue, 24 Sep 2013 08:21:12 -0300 From: Daiane Angolini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Otavio Salvador References: <1379966158-18179-1-git-send-email-otavio@ossystems.com.br> <1379966158-18179-2-git-send-email-otavio@ossystems.com.br> <20130924010445.45f71815@e6520eb> In-Reply-To: X-OriginatorOrg: freescale.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: meta-freescale Mailing List Subject: Re: [meta-fsl-arm PATCH 01/23] fsl-dynamic-packagearch.bbclass: Dynamically set package architecture X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 11:26:04 -0000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable On 09/23/2013 10:04 PM, Otavio Salvador wrote: > On Mon, Sep 23, 2013 at 8:04 PM, Eric B=E9nard wrote: >> H Otavio, >> >> Le Mon, 23 Sep 2013 16:55:36 -0300, >> Otavio Salvador a =E9crit : >> >>> 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 > ... >> 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 b= enefits: > > * 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=20 mesa in poky) Consider to include those justification on commit log. > > Regards, > --=20 Daiane