What I propose is that we spend a little time here and establish some
well thought out standards for the proc interface.
First, byte ordering:
Everyone knows that big endian byte ordering is sane for a /proc interface,
because /proc is designed to be an interface to humans. Besides, we're
taught in big endian format as programmers.
Solution: Use the appropriate htonl type functions if we want to display
Hex for /proc numbers, else we convert to decimal, or have a specific formatting
routine; all of this assumes that the raw data is big-endianized before it's
processed. (Note: is there any specific function or macro that I should use
to make this right???).
Time formats:
It seems to me that expressing the time constants in /proc would be
as simple as:
<seconds>.<microseconds>
If EVER there is a need for processor clock tick, or kernel task switch
interval information, it can be added as a well thought out interface
LATER.
Linus has already expressed this as a sane format that is independent of
the HZ value, etc. The precision of the usec is directly proportional
to the HZ value. You don't change the format of the data to get more
precision; hence, it's portable.
Now, fixing the timing values and fixing the endianess issues seems like
a job I could do for the core kernel stuff if there are any other portability
formatting issues, please follow up on this thread.
For specific drivers in the kernel, people who maintain them may want to
change those, I don't propose to step on people's toes like that.
I'd appreciate any help or comments people could provide. (meanwhile I'll
get the latest sources down and peruse them at home)
--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/