lkml.org 
[lkml]   [1999]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux/IA-64 byte order
Linus Torvalds writes:
>
> On Mon, 8 Mar 1999, David Miller wrote:
> > data. And memory mapping is so much better than plain reading.
> >
> > Actually, besides my per-load/store endianness selection, there is
> > another scheme (supported on UltraSparc, could be supported by IA-64,
> > I don't know).
> >
> > There are often endianness selection bits in the page table entries,
> > add a new flag to mmap, and voila.
>
> Wrong.
>
> Think about "memcpy()" and structures (imagine a structure that
> mixes 16-bit, 32-bit and 64-bit data).

How exactly is that a problem? If you do an access to a page that has
the BE bit set, then whatever size operand you load, the CPU will do
the right thing. So that will just work. You'll only come a cropper if
you want to use memcpy() to copy the data around. But the application
may not need to do that.

> There is no easy solution to bi-endianness. Anybody who thinks there
> is is just sadly misguided. You should aim for having a systemwide
> endianness, anything else is just asking for trouble for absolutely
> no real gain.

That's not really true. I'm less concerned with the byte swapping
overhead. I'm more concerned about the ability to mmap() a huge file
in BE format (I can't change the format) and being able to randomly
bits of it without having to read the whole thing. Having to read the
entire file is a terrible performance suck.

If you don't like the BE-mapping idea, what about the other approach
of mmap()ing a special device that signals the process when a fresh
page is accessed, and discards the page when normally it would be
swapped out?

Regards,

Richard....

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

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.111 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site