> 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.
Okay, I understand you know. For everything that byte order "matters", simply
print it out in a format that is appropriate for representing the native
format of the data (dotted decimal IP addresses for example).
>
> 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.
Gotcha. Hmm, all of this still leaves a lot up to the programmer on how
they want to represent data and get it to the user. I'm gonna think about
how to make proc or some meta fs type thing better. The only problem with
the proc filesystem is that if you change how the data is formatted, you
end up modifying a bunch of different, unrelated source files. Perhaps
we need a centralized meta data fs that you register a callback(s)
with, and you provide a chunk of data in a structure that describes what
the data is, and generalized formatting info (data classes, eg: this is an
integer, this is an IP, this is a bit field, this is a string, etc).
A new /proc type thing is definitely prototype and not 2.2. However fixing
the byteorder things seems logical and doable to me. Making the data
consistent in the current interface is a good idea.
>
> Linus
>
--Perry
-- Perry Harrington Linux rules all OSes. APSoft () email: perry@apsoft.com Think Blue. /\- 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/