[Openembedded-architecture] who should set default tunes?

[Mark Hatle]

On 5/2/17 8:15 AM, Koen Kooi wrote:
> 
>> Op 2 mei 2017, om 15:01 heeft Mark Hatle <mark.hatle at windriver.com> het volgende geschreven:
>>
>> 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)
> 
> No, it wouldn’t be locked to one specific tune, this is what Angstrom and a few other DISTROs use to deal with such anti-social BSPs:
> 
> https://github.com/Angstrom-distribution/meta-angstrom/blob/master/conf/distro/include/arm-defaults.inc
> 
>>
>> 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.
> 
> Every time I asked such BSPs the answers were:
> 
> 1) We didn’t know, we copy-pasted from $BAD_BSP, we’ll fix
> 2) OMG optimization, you are an idiot, go away!
> 3) This vendor ships binary drivers
> 
> Answer 3) is clearly a DISTRO decision, since it involves licensing. 
> 
> So yes, there are reasons, but I haven’t encountered a *good* reason yet that benefits the ecosystem. I’ve encountered 2) twice now, and for one of those the employee no longer works for the vendor, so the situation might improve :)
> 

This is exactly why the BSP should have a ?= behavior if they set whatever the
default is.  And yes, #2 is quite common and often 'more optimized' is a fantasy
brought up by someone in marketing.

--Mark