Re: ARM tunings was Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README

[Phil Blundell <philb@gnu.org>]

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?

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?

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.

p.