On 4/10/12 4:23 AM, Phil Blundell wrote:
On Mon, 2012-04-09 at 16:44 -0500, Mark Hatle wrote:
Depends on the distribution and reasons for these feeds. What is typical is
that a base distribution will be generated for a common compatible (reasonable)
architecture.. i.e. armv5 -- with specific optimized package (glibc, openssl,
etc) for the target arch, i.e. armv7a. Then you have a couple of packages
hand-tuned for size, speed, or other that define or not thumb and add even a
higher level of optimization. It's possible, folks do it today.. but it's not
always obvious. (I have existing customers today that run a mix like I
described through their own package feed like system. They really don't care at
all that the core system is tuned for a given processor -- they only care that
their specific applications and certain areas are specifically tuned to their
use-cases.) Note, this is not what I would consider a typical use-case!
Sorry, I'm not quite sure I understand what point you're trying to make
here. Are you describing what your customers are currently doing with
OE, or are you saying that this is something that they would like to do
with OE but don't feel they are able to at present, or something else?
The company I work for has an existing product that does not use OE. The
customers using this have requested from us packages tagged with different
package architectures to indicate the tuning and optimization information so
that they can create multiple boards with the same software running on them.
(This is closer to the traditional workstation/server model in my experience.)
The multiple boards have a common set of OS applications that run on them.
ARMv5 for the most part. The customers then have optimized applications with or
without thumb, and optimized for a variety of different ARM parts. They then
use the binary packages to assemble the filesystems, and perform field upgrades,
on these boards as they are put into use. The installation system uses a best
to least best match when doing assembly actions. So if the part is an ARMv7a,
it will first look for ARMv7a w/ thumb, vfp and neon, not finding that, ARMv7a
w/ thumb and vfp, then ARMv7a w/ thumb, then ARMv5 w/ thumb and vfp, then ARMv5
w/ thumb, and finally fall back to the ARMv5 binaries.
I'm still not entirely clear on what you feel is broken about the
current state of the ARM tunings. What exactly is the scenario that
works with the "traditional workstaton/server Linux OS" and can't be
replicated with OE?
With the current implementation, there is no package differentiation between
thumb and non-thumb binaries. I accept why this is in OE-core and I can live
with that. However, there are other binaries that are theoretically optimized
from specific Cortex models to the more generic ARMv7a tunings. Currently they
all use the same package arch, which means I can't tell which CPU they're really
for -- and this model (above) of best to least best match doesn't work.
On a pure embedded model, I doubt anyone would do this. Thus it is a fairly
unique embedded use-case, but a common Workstation/Server use case that is being
replicated.
But, all that aside, it seems ultimately that the exact way the
PACKAGE_ARCHs are structured ought to be a DISTRO policy decision and
not something that's mandated by the underlying infrastructure. That
would perhaps remove some of the need for tinkering with these things in
oe-core itself.
I intend, after this release, to propose changes to differentiate the models in
oe-core. If the oe-core folks do not feel this is necessary, they I will
maintain them on my own as I feel necessary to cover the above use-case.
I can very much understand that in OE, for ARM specifically the package arch is
simply indicating basic compatibility and not ABI & ISA & Optimization like it
is on other architectures.
--Mark
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
