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

login
register
mail settings
Submitter Martin Jansa
Date Sept. 22, 2012, 4:51 p.m.
Message ID <5ac0bc525f5ac3f07c5749efc31e91c3fe6145c1.1348330479.git.Martin.Jansa@gmail.com>
Download mbox | patch
Permalink /patch/37059/
State Superseded, archived
Headers show

Comments

Martin Jansa - Sept. 22, 2012, 4:51 p.m.
* 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@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(-)
Richard Purdie - Sept. 22, 2012, 5:45 p.m.
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@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.

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.

Cheers,

Richard
Martin Jansa - Sept. 27, 2012, 8:37 a.m.
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@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 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.

Cheers,
Mark Hatle - Sept. 27, 2012, 6:58 p.m.
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@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...

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

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}"

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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Martin Jansa - Sept. 27, 2012, 7:12 p.m.
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@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@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Mark Hatle - Sept. 27, 2012, 7:18 p.m.
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@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.)

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

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

--Mark

> 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@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Martin Jansa - Sept. 27, 2012, 7:40 p.m.
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@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,
Mark Hatle - Sept. 27, 2012, 7:53 p.m.
On 9/27/12 2:40 PM, Martin Jansa wrote:
> 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@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?

Sorry, not bbappend in this case..  but you can do it in a distribution layer. 
(This is from memory so I might not be 100% correct.)

You should be able to have in your own layer a qemuarm.conf that looks like:

require conf/machine/qemuarm.conf
OPTDEFAULTTUNE = "something"
DEFAULTTUNE = "something_else"

It will know not to open itself in the requires.... and fall back to a previous 
layer.

(If that doesn't work, I know we did it somehow.. since we ran into a similar 
situation with our product.)

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

I agree completely, this is the downside of doing it int he distro files vs the 
tune files.  But in the end it seems reasonable to make it a machine or 
distribution setting of some kind.

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

Yup, no disagreement there.

--Mark

> Thanks again for constructive comment.
>
> Cheers,
>
Martin Jansa - Sept. 27, 2012, 8:16 p.m.
On Thu, Sep 27, 2012 at 02:53:21PM -0500, Mark Hatle wrote:
> On 9/27/12 2:40 PM, Martin Jansa wrote:
> > 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@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?
> 
> Sorry, not bbappend in this case..  but you can do it in a distribution layer. 
> (This is from memory so I might not be 100% correct.)
> 
> You should be able to have in your own layer a qemuarm.conf that looks like:
> 
> require conf/machine/qemuarm.conf
> OPTDEFAULTTUNE = "something"
> DEFAULTTUNE = "something_else"
> 
> It will know not to open itself in the requires.... and fall back to a previous 
> layer.
> 
> (If that doesn't work, I know we did it somehow.. since we ran into a similar 
> situation with our product.)

yes but that's still at least 2 more lines (possibly in separate .conf
file) for each MACHINE I could possibly support by my distro, I would like 
to keep it more universal (or ortogonal in distro/machine/image sense).

> > 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.
> 
> I agree completely, this is the downside of doing it int he distro files vs the 
> tune files.  But in the end it seems reasonable to make it a machine or 
> distribution setting of some kind.
>
> >>> 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.
> 
> Yup, no disagreement there.

Ok, lets see if this changes RP's view on OPTDEFAULTTUNE.

Cheers,
Phil Blundell - Sept. 28, 2012, 11:02 a.m.
On Thu, 2012-09-27 at 13:58 -0500, Mark Hatle wrote:
> 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.

I think we've discussed this before but, just to reiterate, this sort of
thing is a matter of DISTRO policy.  It is perfectly legitimate to want
to build binaries with, say, -march=armv5te -mtune=arm926ej-s and have
them end up with PACKAGE_ARCH="armv5te" or even just "arm".

It seems to me that we are in danger of adding a lot of complicated and
hard-to-understand machinery to oe-core in an attempt to solve a problem
that ought to be getting solved by the DISTRO, and that by doing so we
might be making life harder rather than easier for DISTROs which happen
to want a slightly different labelling model to the default.

p.
Martin Jansa - Sept. 28, 2012, 6:21 p.m.
On Fri, Sep 28, 2012 at 12:02:50PM +0100, Phil Blundell wrote:
> On Thu, 2012-09-27 at 13:58 -0500, Mark Hatle wrote:
> > 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.
> 
> I think we've discussed this before but, just to reiterate, this sort of
> thing is a matter of DISTRO policy.  It is perfectly legitimate to want
> to build binaries with, say, -march=armv5te -mtune=arm926ej-s and have
> them end up with PACKAGE_ARCH="armv5te" or even just "arm".
> 
> It seems to me that we are in danger of adding a lot of complicated and
> hard-to-understand machinery to oe-core in an attempt to solve a problem
> that ought to be getting solved by the DISTRO, and that by doing so we
> might be making life harder rather than easier for DISTROs which happen
> to want a slightly different labelling model to the default.

That's already there with DEFAULTUNE/AVAILTUNES machinery, isn't it?

Having that with better default values doesn't make things worse for
such DISTROs.

Cheers,
Martin Jansa - Oct. 2, 2012, 6:43 p.m.
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@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...
> 
> 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've updated contrib/jansa/tune-test with this.
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test

While changing that to use e.g.
ARMPKGARCH_tune-xscale
I've noticed that _tune-foo are not valid OVERRIDE, so I had to add 
ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
arm tune (otherwise it's expanded like this TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).).

This makes whole
TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
a bit less usefull, maybe ARMPKGSFX_CPU was better approach..

Cheers,

> 
> 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}"
> 
> 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@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Mark Hatle - Oct. 2, 2012, 8:36 p.m.
On 10/2/12 1:43 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@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...
>>
>> 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've updated contrib/jansa/tune-test with this.
> http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test
>
> While changing that to use e.g.
> ARMPKGARCH_tune-xscale
> I've noticed that _tune-foo are not valid OVERRIDE, so I had to add
> ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
> in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
> arm tune (otherwise it's expanded like this TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).).
>
> This makes whole
> TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
> a bit less usefull, maybe ARMPKGSFX_CPU was better approach..

I've clarified with RP on this.  Tune values are not a 'true' override because 
of evaluation time of overrides.  We want the DEFAULTTUNE to be changeable 
during the build process to allow multilibs, alternative configurations, etc.

So in the tunes to do override-like implementations, you will need:

ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"

and then in each tune fragment:

ARMPKGARCH_tune-foo = "bar"

--Mark

> Cheers,
>
>>
>> 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}"
>>
>> 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@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Martin Jansa - Oct. 2, 2012, 8:38 p.m.
On Tue, Oct 02, 2012 at 03:36:16PM -0500, Mark Hatle wrote:
> On 10/2/12 1:43 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@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...
> >>
> >> 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've updated contrib/jansa/tune-test with this.
> > http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test
> >
> > While changing that to use e.g.
> > ARMPKGARCH_tune-xscale
> > I've noticed that _tune-foo are not valid OVERRIDE, so I had to add
> > ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
> > in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
> > arm tune (otherwise it's expanded like this TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).).
> >
> > This makes whole
> > TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
> > a bit less usefull, maybe ARMPKGSFX_CPU was better approach..
> 
> I've clarified with RP on this.  Tune values are not a 'true' override because 
> of evaluation time of overrides.  We want the DEFAULTTUNE to be changeable 
> during the build process to allow multilibs, alternative configurations, etc.
> 
> So in the tunes to do override-like implementations, you will need:
> 
> ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
> 
> and then in each tune fragment:
> 
> ARMPKGARCH_tune-foo = "bar"

Yes that's what I did, but it's a bit ugly, see yourself - 2nd patch from top in that repo

> 
> --Mark
> 
> > Cheers,
> >
> >>
> >> 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}"
> >>
> >> 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@lists.openembedded.org
> >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >>>
> >>
> >>
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
>
Mark Hatle - Oct. 2, 2012, 8:47 p.m.
On 10/2/12 3:38 PM, Martin Jansa wrote:
> On Tue, Oct 02, 2012 at 03:36:16PM -0500, Mark Hatle wrote:
>> On 10/2/12 1:43 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@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...
>>>>
>>>> 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've updated contrib/jansa/tune-test with this.
>>> http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test
>>>
>>> While changing that to use e.g.
>>> ARMPKGARCH_tune-xscale
>>> I've noticed that _tune-foo are not valid OVERRIDE, so I had to add
>>> ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
>>> in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
>>> arm tune (otherwise it's expanded like this TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).).
>>>
>>> This makes whole
>>> TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
>>> a bit less usefull, maybe ARMPKGSFX_CPU was better approach..
>>
>> I've clarified with RP on this.  Tune values are not a 'true' override because
>> of evaluation time of overrides.  We want the DEFAULTTUNE to be changeable
>> during the build process to allow multilibs, alternative configurations, etc.
>>
>> So in the tunes to do override-like implementations, you will need:
>>
>> ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
>>
>> and then in each tune fragment:
>>
>> ARMPKGARCH_tune-foo = "bar"
>
> Yes that's what I did, but it's a bit ugly, see yourself - 2nd patch from top in that repo

Ya, I agree a bit ugly.. but I do think it's reasonable in this case.

--Mark

>>
>> --Mark
>>
>>> Cheers,
>>>
>>>>
>>>> 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}"
>>>>
>>>> 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@lists.openembedded.org
>>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>

Patch

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 ??= ""
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
index c6e5289..4406b3c 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -1,4 +1,5 @@ 
-DEFAULTTUNE ?= "arm926ejs"
+DEFAULTTUNE ?= "armv5te"
+OPTDEFAULTTUNE ?= "arm926ejs"
 ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc
diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc
index 1f47c44..a04a5e1 100644
--- a/meta/conf/machine/include/tune-xscale.inc
+++ b/meta/conf/machine/include/tune-xscale.inc
@@ -1,4 +1,5 @@ 
-DEFAULTTUNE ?= "xscale"
+DEFAULTTUNE ?= "armv5te"
+OPTDEFAULTTUNE ?= "xscale"
 ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-xscale", "", d)}"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc