[Openembedded-architecture] who should set default tunes?

[Mark Hatle]

On 5/2/17 2:36 AM, Koen Kooi wrote:
> 
>> Op 29 apr. 2017, om 17:32 heeft Mark Hatle <mark.hatle at windriver.com> het volgende geschreven:
>>
>> On 4/28/17 11:47 PM, Trevor Woerner wrote:
>>> http://lists.openembedded.org/pipermail/openembedded-core/2017-March/133719.html
>>>
>>> Specifying which CPU a board uses (i.e. in BSP layer) now
>>> automatically chooses hardfp? It's always defaulted to softfp. Was
>>> there a reason softfp was the default? I was under the impression CPU
>>> tuning is a DISTRO decision, not a BSP one?
>>
>> Ultimately it is the BSP that is responsible for setting the proper default tune.
> 
> No it is not. The BSP sets the architecture, the DISTRO decides the ABI. 

I disagree.  The DISTRO sets the various flags and options, but shouldn't have
anything to do with the ABI.  If the distro configures the ABI then the tune can
no longer be arbitrarily changes and the distro is now bound to a specific tune
or architecture class.. (i.e. arm)

DISTRO should be architecture neutral.

>>
>> As noted in this change though, often a BSP will pick up the default from the
>> tune file that it loads.  This is (hopefully) the BSP author intentionally
>> allowing the tune file to set the 'best default', which of course can change
>> over time.
>>
>> What I always tell people is:
>>
>> - If you don't know what you are doing (userspace wise) or don't care -- use the
>> default from the tune file.
>>
>> - If your MACHINE has specific requirements you need to default the default tune
>> (before loading the tune file)
>>
>> - If the project knows better then the MACHINE, you can always switch a default
>> there -- but then you have to remember the default is project specific.
> 
> It is not about knowing better, it is about expectations, suppose I have 2 BSPs:
> 
> 1) meta-ti providing support for the beaglebone black
> 2) meta-crowdfunding proving support for a derivative design with an extra USB port, beaglebone purple
> 
> You are saying that one of those doing hardfp and the other softfp is the right thing. It isn’t. Making it “just work” is what the patches Trevor (and others) sent to the BSPs do: make them follow the OE-core default, leave deviations to $DISTRO.
> 

In the above case, I would expect the user of the BSPs to override the default
tune for both of them to synchronize exactly what they want.  It is not
unreasonable to have a common configuration that says build both machines with a
specific tune so that the underlying feeds can be compatible.

But there may be reasons why one vs the other is using HF or SF by default.

--Mark