From: Dan Malek <dan@mvista.com>
To: Mark Salisbury <mbs@mc.com>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: ppc LE questions (seeking help hand info pointers)
Date: Thu, 20 Sep 2001 18:22:59 -0400 [thread overview]
Message-ID: <3BAA6C43.455873D@mvista.com> (raw)
In-Reply-To: 3BAA0E6F.5050503@mc.com
Mark Salisbury wrote:
> assume I have a valid reason for wanting to run ppc's in LE mode
This is where it starts to fall apart. I didn't know there were
any valid reasons to support LE mode, except to run some software
from a certain company that never materialized. I was fortunate to
be part of the PowerPC design discussions from the beginning. The LE
mode was never popular.
A technical reason is the PowerPC never supported a true little
endian mode. It basically does byte swapping between the cache
and core processing units, and I believe always (or at least usually)
supported a big endian bus. You can't properly attach the processor
to true little endian busses or devices when this is done, so you don't
gain any hardware design advantage. As you know, properly byte
swapping depends upon the size of the object, so if you happen
to access something in smaller units than it's natural size you
aren't going to get the results you expect. For someone that is
comfortable programming in an LE environment (is there anyone? :-),
this will eventually bite you.
Another technical reason is as the processor family moves forward,
less and less little endian support is provided. In the case of
the 7450, there are instructions that trap to the kernel to be
emulated in LE mode, that are executed in the core in BE mode.
> question 2. if 1, what is the primary reason for rejection.
It was LE (sorry, couldn't resist :-)?
> question 3. is there a general issue of endian safety in linux (I would
> think not) or just in the ppc-specific code?
Linux is very aware of endian issues. For all but I guess two of
you now, everyone assumes PowerPC is big endian and we make adjustments
when working on little endian I/O. Without hardware for testing,
the rest of us are just likely to break any LE software, and you
are just going to end up chasing fixes behind lots of the rest of us.
> ..........what would be the primary
> obstacle to inclusion in the main line.
Like I always say, the kernel is the easy part. None of us have
the hardware, tools, libraries, or applications to utilize a LE kernel.
It more than doubles the work we need to do trying to keep the
software up to date, if we had all of that for testing. It may
be easier to just keep your patch up to date, than to try and keep
up with the rest of us making changes to software we can't test.
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-09-20 22:22 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-20 15:42 ppc LE questions (seeking help hand info pointers) Mark Salisbury
2001-09-20 15:58 ` Tom Rini
2001-09-20 16:07 ` Geert Uytterhoeven
2001-09-20 16:12 ` Tom Rini
2001-09-20 17:10 ` Brad Boyer
2001-09-20 18:32 ` Mark Salisbury
2001-09-20 19:29 ` Holger Bettag
2001-09-20 19:35 ` David Edelsohn
2001-09-20 20:19 ` Mark Salisbury
2001-09-21 1:46 ` Timothy A. Seufert
2001-09-21 3:54 ` Dan Malek
2001-09-21 7:24 ` Geert Uytterhoeven
2001-09-21 7:47 ` Dan Malek
2001-09-21 7:50 ` Geert Uytterhoeven
2001-09-21 8:19 ` Dan Malek
2001-09-21 17:01 ` Ralph Blach
2001-09-21 17:35 ` David Edelsohn
2001-09-21 18:58 ` David Edelsohn
2001-09-21 20:22 ` Dan Malek
2001-09-21 20:29 ` Benjamin Herrenschmidt
2001-09-21 20:42 ` Benjamin Herrenschmidt
2001-09-21 7:22 ` Geert Uytterhoeven
2001-09-21 9:26 ` keyb Giuliano Pochini
2001-09-21 10:38 ` ppc LE questions (seeking help hand info pointers) Ralph Blach
2001-09-20 20:01 ` Tony Mantler
2001-09-20 18:28 ` Mark Salisbury
2001-09-20 19:12 ` Tom Rini
2001-09-20 22:22 ` Dan Malek [this message]
2001-09-21 5:45 ` Troy Benjegerdes
2001-09-28 6:37 ` Paul Mackerras
-- strict thread matches above, loose matches on Subject: below --
2001-09-21 5:28 Albert D. Cahalan
2001-09-21 6:10 ` Dan Malek
2001-09-21 10:59 ` Ralph Blach
2001-09-21 18:48 Albert D. Cahalan
2001-09-22 0:22 ` Timothy A. Seufert
2001-09-22 20:06 ` Albert D. Cahalan
2001-09-24 17:10 ` Mark Salisbury
2001-09-22 14:23 ` Holger Bettag
2001-09-22 20:26 ` Timothy A. Seufert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3BAA6C43.455873D@mvista.com \
--to=dan@mvista.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=mbs@mc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).