| 1 |
On 8/11/15 10:33 AM, Ian Stakenvicius wrote: |
| 2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
| 3 |
> Hash: SHA256 |
| 4 |
> |
| 5 |
> On 11/08/15 06:11 AM, Leno Hou wrote: |
| 6 |
>> I think ppc64le would become popular, |
| 7 |
>> https://en.wikipedia.org/wiki/Ppc64. |
| 8 |
>> |
| 9 |
>> 1. enable porting x86 Linux based application with minimal effort. |
| 10 |
>> 2. Some PowerPC user, little endian apparently feels cheap, wrong, |
| 11 |
>> and PCish. 3. Other distrbutions like Ubuntu, Redhat and SUSE |
| 12 |
>> already support little endian in powerpc. |
| 13 |
>> |
| 14 |
>> |
| 15 |
> In terms of the codepaths, what's different between ppc64le vs ppc64, |
| 16 |
> and ppc64le vs amd64 ? Obviously kernels will differ, but in terms of |
| 17 |
> C/C++/other compiled source code what needs to change? |
| 18 |
> |
| 19 |
> If all this needs is its own profile for a CHOST/CBUILD specification |
| 20 |
> and it can leverage an existing keyword, then this should be rather |
| 21 |
> simple to implement yes? |
| 22 |
|
| 23 |
We would leverage this on ppc64 keyword. It is a bit dangerous to claim |
| 24 |
that a pkg stable on ppc64 is stable on ppc64le, but we would live with |
| 25 |
that risk. Ideally you should test on both. The situation is analogous |
| 26 |
to mips where there are many different ISAs and both be and le. It is |
| 27 |
one of the reasons mips is hard to move back into stable. But having |
| 28 |
stable keywords is really nice when it comes to building and maintaining |
| 29 |
stages and keeping base pkgs versions in sync with the other arches. |
| 30 |
For this reason, I would even been in favor of restoring stable mips |
| 31 |
with the understanding that "stable" carries something of a risk when |
| 32 |
crossing the be/le boundry, or the mips I vs mips III, or 32 vs 64, etc. |
| 33 |
|
| 34 |
Having said that, what would break? Assembly and other code that makes |
| 35 |
assumption about byte order. There is some out there, but not much. |
| 36 |
We'll deal with it when we hit it. Any of the heavy duty stuff, like |
| 37 |
syscall interfaces or setjmp/longjmp etc, should be relegated to the |
| 38 |
libc and kernel. |
| 39 |
|
| 40 |
> |
| 41 |
> |
| 42 |
> |
| 43 |
> -----BEGIN PGP SIGNATURE----- |
| 44 |
> Version: GnuPG v2 |
| 45 |
> |
| 46 |
> iF4EAREIAAYFAlXKB7UACgkQAJxUfCtlWe1sbQD+KcbYpfo56GrLIVlFyw2iXbMB |
| 47 |
> ZOWzuvyI8SVq/DY0SQMBAJgDIjCza8QyUgWEtq2/g5Yu+uWiCibf2ouMeNAOkQ33 |
| 48 |
> =YoUg |
| 49 |
> -----END PGP SIGNATURE----- |
| 50 |
> |
| 51 |
|
| 52 |
|
| 53 |
-- |
| 54 |
Anthony G. Basile, Ph.D. |
| 55 |
Gentoo Linux Developer [Hardened] |
| 56 |
E-Mail : blueness@g.o |
| 57 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 58 |
GnuPG ID : F52D4BBA |
Archives