Messages in this thread | | | From | Perry Harrington <> | Subject | Re: ARMS WAVING!!! Proposal to fix /proc dainbrammage. | Date | Fri, 23 Oct 1998 15:58:24 -0700 (PDT) |
| |
> 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. >
> 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/
| |