[OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default

Thu Sep 27 19:40:59 UTC 2012

On Thu, Sep 27, 2012 at 02:18:07PM -0500, Mark Hatle wrote:
> On 9/27/12 2:12 PM, Martin Jansa wrote:
> > On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
> >> Let me preface this by I have read the patch set.. Martin asked me to comment on
> >> the items below...
> >>
> >> On 9/27/12 3:37 AM, Martin Jansa wrote:
> >>> On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
> >>>> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> >>>>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
> >>>>> * this way xscale or arm926ejs is not used by default when some machine
> >>>>>     includes its tune*.inc, but it's easy for DISTRO to say it wants
> >>>>>     OPTDEFAULTTUNE for some packages or always (if they don't want to
> >>>>>     share built packages between xscale and arm926ejs).
> >>>>>
> >>>>> Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> >>>>> ---
> >>>>>    meta/conf/bitbake.conf                       | 1 +
> >>>>>    meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
> >>>>>    meta/conf/machine/include/tune-xscale.inc    | 3 ++-
> >>>>>    3 files changed, 5 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >>>>> index 9b41749..e433fcb 100644
> >>>>> --- a/meta/conf/bitbake.conf
> >>>>> +++ b/meta/conf/bitbake.conf
> >>>>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
> >>>>>    HOST_AS_ARCH = "${TARGET_AS_ARCH}"
> >>>>>    HOST_EXEEXT = ""
> >>>>>
> >>>>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
> >>>>>    TUNE_ARCH ??= "INVALID"
> >>>>>    TUNE_CCARGS ??= ""
> >>>>>    TUNE_LDARGS ??= ""
> >>>>
> >>>> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
> >>>> or in meaning and we need to find a better solution. I'm therefore not
> >>>> keen on this change.
> >>>
> >>> OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
> >>> different PKGARCH for different TUNE_CCARGS?
> >>
> >> I've been an advocate for a while that the processor optimization (CCARGS) does
> >> make it into the PKGARCH.  ARMPKGSFX_CPU seems like a reasonable approach to do
> >> this.  It allows each tune to set something to tell people what that binary is
> >> really built for, and for the 'base' tunes (i.e. armv5) it can be left off.
> >>
> >> The only concern I have with that is:
> >>
> >> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
> >> "-arm926ejs", "", d)}"
> >>
> >> That probably should be a .= instead of just '='.  That way if the user loads
> >> multiple compatible tunes the right ARMPKGSFX_CPU will be used.  (Alternatively
> >> using the overrides would work as well for this.. i.e.
> >> ARMPKGSFX_CPU_tune-arm926ejs instead...
> >
> > OK.
> >
> >> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...  This is
> >> fine as well, and it was designed to be overriden.. but again the .= or
> >> -tune_... syntax should be used...
> >
> > I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.
> >
> > But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS:
> > PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
> > do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like
> > armv4t-xscale?
> >
> > Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update
> > would try to download many feeds but only a few does exist).
> 
> The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names. 
> Which of course feed into the list of feeds used by the various packaging 
> systems.  I think it's up to the distribution to modify or limit the feeds 
> resolved, but I don't know if there is a clean way to do this.  I always error 
> on listing more then less, because I don't know how people are going to want to 
> mix and match things.  (And a BSP or end user can always just define what the 
> PACKAGE_EXTRA_ARCHS value should be.)

Yes that's what I do now, but I'm not too happy about it :/
SUPPORTED_EXTRA_ARCHS ?= "armv4t armv5te armv6-novfp armv7a-vfp-neon x86_64 x86"
SUPPORTED_EXTRA_ARCHS_armv7a ?= "armv7a-vfp-neon"
SUPPORTED_EXTRA_ARCHS_armv6 ?= "armv6-novfp"

> >> Anyway, my point in this is I like having the stuff unique, but we need to be
> >> sure that you can specify more then one tune file during a build w/o clashes.
> >>
> >>>> I also still think this is a distro packaging issue and should be solved
> >>>> by the distro, even if that means more complexity there. That is the
> >>>> right place for this particular complexity IMO. I'm happy to support
> >>>> that from the core but not in something as user visible and confusing as
> >>>> this variable.
> >>>
> >>> Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
> >>> there will be much worse then when it's defined in tune-* files, because
> >>> now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
> >>> TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
> >>> config) then it could be.
> >>
> >> I really don't have a strong opinion on this either way.  I know for the stuff
> >> I've done in the past (not oe-based) we've just manually configured (the
> >> equivalent of the distro conf) with the information on the handful of items that
> >> people wanted optimized the most...  eglibc, openssl, mysql/posgresql...
> >> otherwise folks don't seem to care, and re-use works fine.
> >>
> >> If the list is small (i.e. less then 10 packages) that specifying it via package
> >> specific overrides in the distro file should be fine.. if it's more then 10
> >> (typically) then we need to start looking for another approach.
> >>
> >> I'd almost suggest in the distro file you could do:
> >>
> >> OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or
> >> elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
> >>
> >> DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
> >
> > Yes but first I have to say:
> > DEFAULTTUNE_spitz = armv5te
> > OPTDEFAULTTUNE_spitz = xscale
> > DEFAULTTUNE_qemuarm = armv5te
> > OPTDEFAULTTUNE_qemuarm = arm926ejs
> > or
> > DEFAULTTUNE_tune-xscale = armv5te
> > OPTDEFAULTTUNE_tun_xscale = xscale
> > DEFAULTTUNE_tune-arm926ejs = armv5te
> > OPTDEFAULTTUNE_tune-arm926ejs = arm926ejs
> >
> > to know what's OPTDEFAULTTUNE and DEFAULTTUNE for given MACHINE if it's
> > not in defined tune-xscale/tune-arm926ejs.
> 
> I assume that a distribution will be (bb)appending, or defining their own BSPs. 
>   And in that case it's pretty easy to add both the DEFAULTTUNE and 
> OPTDEFAULTTUNE line to the BSP configuration file.  (And if someone uses a 
> different distribution, then the DEFAULT is used as that is the standard method.)

Yes, but how should I .bbappend machine config? e.g. qemuarm.conf in
oe-core? 

Yes I can add that to my BSPs, but if I call it OPTDEFAULTTUNE
then everybody else (who is interested in my BSP but has own distro)
needs to agree on name OPTDEFAULTTUNE.

That's why I wanted this defined in tune-* files which are shared in
oe-core and used by everybody I guess.

> > And that's what I didn't want to include in my distro config (and then
> > explaining to someone that when adding MACHINE foo he has to send patch
> > for distro config).
> 
> Ya I understand.  This is an odd situation for many embedded systems.  You want 
> to reuse packages that aren't optimally tuned -- but you still want a few tuned 
> packages.  It's certainly a usecase we need to support -- but I'm not sure in 
> the end how people end up doing this.
> 
> I know most of my commercial customers just want everything to be tuned for the 
> target BSP.. and they build new distributions for each product they implement.

Ok, but having both OPTDEFAULTTUNE and DEFAULTTUNE in tune-* allows both
use cases to coexist without any complex configuration on distro side.

Thanks again for constructive comment.

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120927/aa9ded76/attachment-0002.sig>