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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 1 Oct 2010 07:36:35 -0400
From:	Josh Boyer <jwboyer@...il.com>
To:	Ian Munsie <imunsie@....ibm.com>
Cc:	linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
	benh@...nel.crashing.org, paulus@...ba.org
Subject: Re: Introduce support for little endian PowerPC

On Fri, Oct 1, 2010 at 3:05 AM, Ian Munsie <imunsie@....ibm.com> wrote:
> This patch set in combination with a patched GCC, binutils, uClibc and
> buildroot has allowed for a full proof of concept little endian environment on
> a 440 Taishan board, which was able to successfully run busybox, OpenSSH and a
> handful of other userspace programs without problems.

Aside from my general "uh, why?" stance, I'm very very hesitant to
integrate anything in the kernel that doesn'.t have released patches
on the toolchain side.

Also, which uClibc?  The old and crusty uClibc that uses the horrible
linuxthreads, or the somewhat less crusty that just switched to NPTL
(which hasn't been verified on normal PowerPC that I recall).  Why not
use glibc...

> This is not yet complete support for little endian PowerPC, some outstanding
> issues that I am aware of are:
>  * We only support 32bit PowerPC for now (and indeed, only 44x)
>  * The vdso has not been fixed to be endian agnostic - any userspace program
>   accessing it will get an unexpected result.
>  * I have not touched PCI at all
>  * Remaining device tree accesses still need to be examined to ensure they are
>   correctly handling the endianess of the device tree.
>  * Any other driver that uses the device tree is likely be broken for the same reason.
>  * I've included a patch for the alignment handler, however it is as yet
>   completely untested due to a property of the hardware I've been using for
>   testing.

I'm not meeting to detract here, but the Kconfig should be dependent
on && BROKEN until the above is fixed.

josh
--
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/