Linus Torvalds writes:
> The only sane interface is a seconds-based one, either like /proc/uptime
> (ie ASCII floating point representation) or a mixed integer representation
> like timeval/timespec where you have seconds and micro/nanoseconds
> separately.
Anything wrong with 64-bit nanoseconds? It's easy to work with,
being an integer type, and it survives the year 2038.
> That's something we should strive for, but I also think we should avoid
> using the clock_t format at all, and give alternate representations (for
> example, leave the broken clock_t representation in /proc/<pid>/stat
> alone, and just add a _sane_ seconds-based thing in the much more readable
> and parseable /proc/<pid>/status file.
Other than the parentheses issue, /proc/<pid>/stat can
be handled with sscanf. Nobody dinks with the format.
People "correct" the spelling and formatting in the
fancy /proc files. Is it "SigCgt" or "SigCat"? That
depends on the kernel version; somebody "fixed" the
spelling.
There isn't any BNF for any /proc file. The raw files
are easy to handle, but one can only guess at what
others will assume about the format of a fancy one.
Take /proc/cpuinfo for example. Long ago, it was like
this:
foo some value
bar 1 2 3 4 5
baz 8000:0
Then it turned into this:
foo : some value
bar : 1 2 3 4 5
baz : 8000:0
uh oh : 69
Who could have guessed?
Stuff broke. Formatted files are too damn tempting
to muck with. People don't touch the ugly files.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:26 EST