[Openembedded-architecture] who should set default tunes?

[Trevor Woerner]

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?

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.


[1] choices could include upstream vs vendor kernel, accelerated
graphics with binary blobs vs reverse-engineered components, -rt
kernel...