Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Benjamin Herrenschmidt <benh <at> kernel.crashing.org>
Subject: Re: Introduce support for little endian PowerPC
Newsgroups: gmane.linux.ports.ppc.embedded
Date: Friday 1st October 2010 12:14:43 UTC (over 7 years ago)
On Fri, 2010-10-01 at 07:30 -0400, Josh Boyer wrote:
> 
> > From a community aspect is anyone actually going to use this?  Is
> this going to be the equivalent of voyager on x86?  I've got nothing
> against some of the endian clean ups this introduces.  However the
> changes to misc_32.S are a bit ugly from a readability point of view.
>  Just seems like this is likely to bit-rot pretty quickly.
> 
> I'm with Kumar on this one.  Why would we want to support this?  I
> can't say I would be very willing to help anyone run in LE mode, let
> alone have it randomly selectable. 

There's some good reasons on the field ... sadly.

At this stage this is mostly an experiment, which went pretty well in
the sense that it's actually quite easy and a lot of the "fixes" are
actually reasonable cleanups to carry.

Now, the main reasons in practice are anything touching graphics.

There's quite a few IP cores out there for SoCs that don't have HW
swappers, and -tons- of more or less ugly code that can't deal with non
native pixel ordering (hell, even Xorg isn't good at it, we really only
support cards that have HW swappers today).

There's an even bigger pile of application code that deals with graphics
without any regard for endianness and is essentially unfixable.

So it becomes a matter of potential customers that will take it if it
does LE and won't if it doesn't ...

Now, I don't have a problem supporting that as the maintainer, as I
said, from a kernel standpoint, it's all quite easy to deal with. Some
of the most gory aspects in misc_32.S could probably be done in a way
that is slightly more readable, but the approach is actually good, I
think, to have macros to represent the high/low parts of register pairs.

So at this stage, I'd say, let's not dismiss it just because we all come
from a long education of hating LE for the sake of it :-)

It makes -some- sense, even if it's not necessarily on the markets
targeted by FSL today for example. At least from the kernel POV, it
doesn't seem to me to be a significant support burden at all.

Cheers,
Ben.
 
CD: 14ms