[Openembedded-architecture] who should set default tunes?

[Mark Hatle]

On 5/2/17 12:14 PM, Trevor Woerner wrote:
> At the core of my question is: what are we fixing?
> 
> In my case, I know softfp builds built and worked fine on the two
> boards I was working with at the time. I could do a more expansive
> test with other BSPs and boards, but do people know of any places
> where the previous OE default softfp tuning was broken such that it
> either didn't build or, would build but then fail to run on the target
> hardware?

In this particular case, the change was from SF to HF.  Due to the perception
that HF ABI is better, best and must be used.. (being driven by ARM, Linaro and
others.)

In my opinion, SF is 'more compatible', HF is more optimized.  You have to make
a decision based on that (and other criteria) to decide which to use.

> I know that commit messages aren't easy and it isn't hard to find
> examples of commit messages I've made that aren't great, but in this
> case a very fundamental change is being made with no explanation.
> Worse still, this commit purports to define a Yocto Project-wide
> policy that leaving tuning decisions up to the DISTRO is probably not
> a good thing.
> 
> These discussions keep coming back to the basic struggle between
> "Yocto the DISTRO-creating tool" and "Yocto the image generating
> tool". In my opinion a good BSP should provide the user with the
> *pieces* they need to create whatever they want (i.e. "Yocto the
> DISTRO-creating tool"), but in no way force them down any one path[1].
> A BSP that assumes the user, by merely using their BSP, wants a
> specific functionality (and therefore must, for example, enable
> hardfp) is acting like an image generating tool. Just because a BSP
> provides recipes for using binary blobs does not mean it must set the
> tuning for anyone wanting to use the BSP to match those recipes. A
> simple check can be made in recipes requiring a specific tuning to
> error out and tell the user their choices are incompatible if it
> detects the tuning and the recipe don't match (and there are examples
> of BSPs that do this). That would be a much more polite BSP rather
> than one that says "oh, you're using me? then let me make all these
> choices for you. obviously *this* is what you want".
> 
> DISTROs generate and maintain package feeds, not BSPs; does it not
> follow that DISTROs should set tuning? How can a BSP possibly know
> what the user wants? But knowing what the user wants is exactly the
> job of the DISTRO.

This is the problem I see.  The DISTRO is all about how the userspace packages
are assembled and configured.  But it doesn't (usually) know anything about the
architecture.  The image (recipe) is what know how to assemble the packages into
something that should boot.

Only the BSP itself knows what hardware we're going to run on.  It's inclusion
of the tune files (and setting of the tune, either implicitly or explicitly) is
done so that the distribution (packages) built for that hardware, and assembled
in the image work in the best reasonable way, according to the BSP developer.

But in the end it's the build project that ultimately knows what level of
compatibility is desired, what level of optimization, etc.  This is why I say
it's really up to the project to define the tune, if you want specific
optimizations -- or -- compatibility, etc.


We have to meet the various expectations throughout the system.

- Definition of a wide variety of 'tunes' that can be used to product the right
optimizations for the right users.

- Definition of a BSP with a 'reasonable' default that matches the goals of the
BSP developer between compatibility, optimization, etc.

- individual 'project' (device?) developer who knows -exactly- what
optimizations, compatibility, etc requirements that they have.

The scope of the individual or organization doing any of these pieces of the
project can change dramatically in knowledge and ability.  So reasonable
defaults are the goal to push, with the end project having ultimate control over
the the end configuration.

--Mark

> 
> [1] choices could include upstream vs vendor kernel, accelerated
> graphics with binary blobs vs reverse-engineered components, -rt
> kernel...
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>