On 11/4/10 1:43 PM, Leon Woestenberg wrote:
On Thu, Nov 4, 2010 at 7:18 PM, Mark Hatle<email@example.com> wrote:
On 11/4/10 1:02 PM, Leon Woestenberg wrote:I don't see how we could be "final" on this, it seems a returning
I think this is an area we need to coordinate.. I'm not against calling is
and for e500v2:In OpenEmbedded we use the core variant as the packaging name:
-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe
Neither of those would be compatible with the existing "ppc" packaging
We will need to generate at least one new packaging arch type, likely 2
(one for each). Maybe called ppc_spe or something similar?
TARGET_CC_ARCH = "-mcpu=8548 -mspe=yes -mabi=spe -mhard-float
BASE_PACKAGE_ARCH = "ppce500v2"
FEED_ARCH = "ppce500v2"
PACKAGE_EXTRA_ARCHS += "ppce500v2"
Does that make sense?
ppce500v2 for right now. However, I think this is a place we need to
coordinate efforts. I'm going to attempt to pull together a list of Linux
ABIs& potential optimizations in the Yocto wiki.
The reason I bring this up is that over the years at Wind River, and my
previous experience at MontaVista... and watching Emdebian and other
projects.. _everyone_ names their package architectures differently..
because people only have a small view on the problem. We finally have
enough history to have a chance at indicating what the actual ABIs are, and
how the compatibility matrix may fill out. (also giving us a change to
finally give these architectures reasonable naming schemes!)
topic every few years.
To bring in the OpenEmbedded arch namespace and our optimizations,
from the "master" branch at OpenEmbedded:
This is a place where I think the Yocto Project can help. We're likely never going to have a final answer.. but what we'll be able to do is give these impromptu ABIs reasonable names so when people talk, everyone can be talking about the same thing..
Then within the Yocto Project's build environment we can promote these namings as part of the implementation...
Open Embedded, and everyone else has legacy associated with their names, which we can try to either coordinate -- or at least help document...