[Openembedded-architecture] who should set default tunes?

[Denys Dmytriyenko]

On Tue, May 02, 2017 at 08:21:09AM -0500, Mark Hatle wrote:
> 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

Agree. You may call it a "suggested" default :)


> often 'more optimized' is a fantasy brought up by someone in marketing.

LOL :) Yeah, I was being polite in my previous email, but it took me some 
convincing internally that using armv7 to share prebuilts is better than 
'more optimized' fantasy...

-- 
Denys