On 10.04.2012 19:53, Mark Hatle wrote:
We still do not have a clean answer for how to resolve the concerns in
the recent thread "conf/machine/include: Cleanup MIPS tunings to match
README". The following is in response to a request I received to
summarize the discussion so far, and include the options to resolve the
issue for the current OE-Core release.
If you are interested in this, please be sure to read until the end
before commenting.
Background:
About 2 weeks ago, in response to a number of patches sent for PowerPC
issues, I set to the task of documenting and cleaning up the various
tune files. It was discovered that since they were originally
implemented, a number of minor conflicts and defects had crept into the
system. The recent patch set added a number of README files and
attempted to resolve any duplication, or confusion between items.
During this work it was discovered that there were two tunings that
produced the same package architecture:
mips (tune), optimized for mips1 - o32 ABI, produced packages with a
"mips" arch
mips32 (tune), optimized for mips32 - o32 ABI, produced packages also
with a "mips" arch.
While "mips1" should work on a "mips32" system, the reverse is not
true. There was no way to distinguish, in a package feed, the
difference between the two sets of binaries.
I updated the MIPS tune files to resolve this issue. The result was:
mips (tune), mips1 - o32 ABI, produced packages with a "mips" arch
mips32 (tune), mips32 - o32 ABI, produced packages with a "mips32" arch
This lead to the thread mentioned above. At first there were concerns
that the GNU target arch had changed (from mips to mips32), this was not
the case. The only change is in the produced package arch names. So
the package feeds and image generation are the only components affected
by this change.
After various discussion with folks, such as Khem Raj, it is unlikely
that anyone would be using oe-core with a "mips1" target. There may be
some mips3 or mips4 targets, but we find it highly unlikely based on our
current experience. Khem suggested resolving this my simply making the
"mips" include mips32 as the default optimization.
Image generation was verified to produce the same images before and
after this change for the qemumips target. I am unable to verify the
package feeds, as I do not have a suitable setup for this.
So possible solutions to this particular issue, which we do need on
prior to the upcoming release:
1) Revert the behavior and match that last release. We have two tunes
that produce different binaries w/ the same "mips" package arch.
* This preserves previous behavior, but IMHO continues to implement
the defect
mips (tune) - mips1 processor, o32 ABI - mips package arch
mips32 (tune) - mips32 processor, o32 ABI - mips package arch
2) Keep it as it is currently checked in. Provide the ability to build
a basic "mips" and a more optimized "mips32" tuned target and package set.
* This fixes the defect and provides the opportunity for "mips" to be
a basic common package arch, while mips32 (or additional mips3? mips4?
mips32r2?) tunes could be used to augment this for specific systems.
mips (tune) - mips1 processor, o32 ABI - mips package arch
mips32 (tune) - mips32 processor, o32 ABI - mips32 package arch
If the tune should reflect the optimization, then mips should be renamed
to mips1 and specified explicitly using -march=mips1, in order to
protect against changing defaults when using a newer compiler. However,
as Phil pointed out, there are many more optimization settings, e.g. -O2
vs. -Os, that aren't encoded into the package arch, so the goal to have
distinct package archs for different binaries won't be reached.
I don't see what a common "mips" package arch would give us. Within OE,
you'd usually compile all your applications for the package arch of your
target system. Adding compatible package archs to the feed just
increases the complexity of online updates.
3) Define only one mips tune, with a target package arch of "mips".
Changing the basic mips tune, and corresponding mips package arch to
include mips32 optimizations and instructions.
* This preserves the "mips" tune, but changes the behavior of the
tune from default compiler, to mips32 optimization
* Anyone requiring mips3 or mips4 will need to add a tune, and that
tune will not be compatible with "mips"
Also, mips1 could be added back anytime if anybody starts using it.
mips (tune) - mips32 processor, o32 ABI - mips package arch
3a) Preserve the mips32 tune entries, but define it as being equal to
mips
* Preserves the tune entries for compatibility, but is anyone
directly using them?
3b) Remove the mips32 tune entries -- effectively eliminating mips32
as a tune
* Removes the tune entries (cleans up the tunes), no compatibility
-- but it's unlikely anyone was directly specifying "mips32" as their
machine's DEFAULTTUNE.
Actually I have (had) machines specifying mips32el and mips32el-nf as
their DEFAULTTUNEs, which your first patch, that got applied upstream,
broke. But I've already switched to use your latest patch using mipsel
and mipsel-nf instead, (which I prefer over the former).
My recommendation is either 2 or 3. The 3a/b variation is simply an
implementation detail to me, and I will be happy to implement it either
way if this is the chosen direction.
I'm fine with either way that restores mips/mipsel for mips32 targets
*before the release*, because the online update feeds broke and all
packages had to be built again from scratch.
