What?
Either the data is numbers, or it isn't.
If it's plain integer numeric data, then there are no byteorder issues.
You print it out as a integer (wheter octal, hex or decimal doesn't
matter). Byteorder is irrelevant, because 12345 is always twelvethousand
threehundredfortyfive. There are no bytes to swap.
If the data has some relevance outside the "integer" space, then you print
it out as the relevant data. You print out text as text, IP numbers as IP
numbers, etc.
> We describe memory addresses in MSB in /proc/xxx/maps, but the data
> stored at those addresses is in LSB format.
No. We describe memory addresses as integers. That's something that is
true regardless of the architecture. You shouldn't consider them to be a
stream of bytes at all.
> See what I'm trying to get at?
No. Parsing an integer is easy, and is completely independent of
byteorder. Nobody has problems parsing the integer 0x1234 - every machine
out there will get the same answer.
It's only when the data has some "structure" that the notion of byte order
matters.
And I'm arguing that when it has structure, we should show the
_structure_, not the bytes. And when you do that, "byteorder" goes away as
a problem, because now you see the structure and the ordering is a purely
structural one rather than some "what order do I deposit bytes in memory
in?" problem.
See? There are no byte order problems with "123.456" - everybody agrees
that it is a floating point number somewhere between the integers 123 and
124. And that's regardless of how they represent the actual bits in
memory.
Linus
-
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/