[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:12:46 UTC 2012

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).

> 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.

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).

Cheers,

> and then everything can be encapsulated into the distro file (and distro BSPs). 
>   The downside of this approach is that it's not the 'standard' implementation.
> 
> --Mark
> 
> > Cheers,
> >
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core at lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
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/cfbf5c92/attachment-0002.sig>