[OE-core] [oe-core][RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Mark Hatle
mark.hatle at windriver.com
Thu Sep 27 19:18:07 UTC 2012
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.)
>> 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 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
>
More information about the Openembedded-core
mailing list