Messages in this thread | | | Date | Tue, 9 Mar 1999 17:52:30 +1100 | From | Richard Gooch <> | Subject | Re: 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/
| |