[Openembedded-architecture] who should set default tunes?

[Mark Hatle]

On 5/2/17 3:53 PM, Phil Blundell wrote:
> On Tue, 2017-05-02 at 15:29 -0500, Mark Hatle wrote:
>> On 5/2/17 2:41 PM, Phil Blundell wrote:
>>>
> - what upgrade and/or downgrade paths it wants to provide;
>>>
>>> - what political considerations (e.g. around endianness) it might
>>> have
>>> to take into account;
>>>
>>> - and no doubt many other things that might influence binary
>>> compatibility in one way or another.
>>
>> local project or BSP (via the tunes) is what I use to set these.  My
>> distributions don't have these concerns.
> 
> If your distributions don't have those concerns then they are not
> distributions, at least not in the sense that we've previously used
> this terminology in OE.  I think a lot of what you consider to be
> "local project" configuration is what would by previous OE conventions
> be part of the DISTRO.  Indeed, central to the concept of a DISTRO is
> that it completely defines the binary compatibility layer and,
> consequently, admits no local tinkering that would have an impact on
> the ABI of the binaries it generates.  It sounds as though the meaning
> you are ascribing to DISTRO is more like "collection of source package
> options" and less like "full set of policies that will result in a
> coherent binary distribution".

A DISTRO to me is:

How do I collectively configure all of the sources to work together and create a
cohesive system.  So it's about configuration of the individual parts, as well
as settings that affect everything as a whole.

The ABI really doesn't matter in that case.  (I build distros for a large number
of architectures, optimizations and abis.  If something does not work with a
specific combination, it's not generally the DISTRO job to sort that out --
instead the recipes (image, packagegroup, individual) is where I've put blocks
and preventing from things coming in.

> If you take a pre-existing DISTRO and then make some sort of
> configuration change to it via local.conf such that it is no longer
> binary compatible, you have effectively forked it into your own
> distribution.  That's not necessarily a bad thing, but it's no longer
> the same DISTRO.

I don't see binary compatibility as a 'DISTRO' thing.  I see it as a project thing.

But I do see system wide 'distro flags' or packageconfig changes that make
changes to produced packages as something to NOT do in a local.conf.

> Now, of course, it would be perfectly legitimate for a DISTRO to say
> that it doesn't care at all about binary compatibility between
> MACHINES, that it wants to build everything with PACKAGE_ARCH = MACHINE
> and that it wants every binary to be tuned to the limit.  In that
> situation it might be useful for the BSP to expose some information
> that the DISTRO could use to obtain these results, i.e. "these are the
> settings that, if no other considerations apply, I would like you to
> use".  But this should not diminish the primacy of the DISTRO when it
> comes to making its own ABI choices.

So I want a single distribution to work on:

IA32 - Core2 and better, 32-bit and 64-bit
ARM64 - armv4 (SF), armv7 (hf), and 64-bit
MIPS32 - o32
MISP64 - n32 and n64
PPC - 32 - hard float, soft-float and e500

Setting those switches inside of the distribution would be nearly impossible and
doesn't buy me any compatibility at all.

The individual machines I select know the defaults they need to work with for
the ABIs.

If I choose two machines that have some specific set of optimizations, then I'm
going to decide the optimization is worth it, or override that to a common set
as part of my local.conf.... since only I know what combinations and options I
need/want.

If you start making these decisions in the DISTRO file, then the distro file is
no longer 'generically useful' across the breadth of OE, but is now specific to
-your- configuration.  While this is ok from a syntactic perspective, it is now
how I prefer to develop.

(I'm looking at this very much from an OSV point of view -- and also as someone
who doesn't care what the hardware platform is.  I've been keeping things as
hardware agnostic as possible [userspace wise] for as long as I've been doing
Linux.)

So another way to look at it.

A distro defines the basic userspace configuration.

A BSP (machine) devices a specific hardware configuration.

An image (recipe) defines the filesystem contents.

(WIC config the partition layout...)

and the local.conf is specific to a project and how I want to override all of
the above.  (With the understanding, the more I override the more I have to
maintain.)

--Mark

> p.
>