Messages in this thread | | | Date | Fri, 23 Oct 1998 15:46:17 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: ARMS WAVING!!! Proposal to fix /proc dainbrammage. |
| |
On Fri, 23 Oct 1998, Perry Harrington wrote: > > If we don't have a standard for byte orders, how is the data going to > make sense???
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/
| |