[Openembedded-architecture] who should set default tunes?

[Denys Dmytriyenko]

On Tue, May 02, 2017 at 01:14:44PM -0400, 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?
> 
> 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

Yes, like this:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb#n13


> 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.

I see an issue with this line of thought - there are users that don't 
understand all the details and dependencies between BSPs and DISTROs. They 
usually don't care about any specific DISTRO. They just want to boot their 
board, they grab what they find on the Internet and try to make it work - 
be it either OE-Core distroless setup, or even trying to configure a custom 
minimal DISTRO of their own. So, they do expect the defaults to be sane - 
so what's wrong with a "soft default"?

Sure, OE-Core defaults can go either way - soft or hard. But at least for 
my meta-ti BSP it would be preferable to default to hardfp - I want the 
default tune to maximize the benefits of my BSP. And DISTROs can surely 
override that, if required.


> [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
>