Assuming "normal" alignment, if we did 'write(fd,&foo,sizeof(foo))',
I would expect to see output like this (in hex for clarity):
ab00000000000000abbc000000000000ababcdcd00000000ababababdededede
^ ^ ^ ^
foo.a foo.b foo.c foo.d
If a BE process sees something like this, the simple example works:
00000000000000ab000000000000bcab00000000cdcdababdedededeabababab
^ ^ ^ ^
foo.a foo.b foo.c foo.d
It's possible for the simple example to work with that layout and a
bit of CPU support, but as soon as you start trying to pass pointers
(or relative character offsets in the case of shared memory) to members
of foo, you get confused. You also get confused if you're not aligned.
If the kernel just uses the page table endianness bit to set the byte
order of all multi-byte load/store instructions to that page, then
everything works more or less the way it is expected to (even on unaligned
accesses). In fact, in that case the CPU doesn't have a "native" byte
order at all, except perhaps when manipulating the page tables themselves.
The one caveat is that you can't do a memcpy() from BE to LE and
vice-versa. If you do, then you have BE data on an LE page and the magic
translation doesn't work properly any more.
On the other hand, the kernel could keep an opposite-endian page or two
around and copy parameters from opposite-endian user processes to that.
Applications would be on their own of course. That would eventually get
unbelievably ugly, especially if a memcpy happens across a page boundary.
<shiver>
Just don't go there.
-- Zygo Blaxell, Linux Engineer, Corel Corporation, zygob@corel.ca (work), zblaxell@furryterror.org (play). It's my opinion, I tell you! Mine! All MINE! Size of 'diff -Nurw [...] winehq corel' as of Wed Mar 10 11:14:00 EST 1999 Lines/files: In 2058 / 29, Out 5773 / 59, Both 7821 / 85- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/