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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev