linux-kernel - Re: Introduce support for little endian PowerPC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <BBD78246-343E-4A96-9E55-3E40AD628C0B@kernel.crashing.org>
Date:	Fri, 1 Oct 2010 12:59:31 -0500
From:	Kumar Gala <galak@...nel.crashing.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Josh Boyer <jwboyer@...il.com>, paulus@...ba.org,
	linuxppc-dev@...ts.ozlabs.org, Ian Munsie <imunsie@....ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Introduce support for little endian PowerPC


On Oct 1, 2010, at 7:14 AM, Benjamin Herrenschmidt wrote:

> 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.

I'm not against it, and I agree some of the patches seem like good clean up.  I'm concerned about this bit rotting pretty quickly.

- k

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/