Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: What is supposed to replace clock_t? | Date | Sat, 13 Jul 2002 16:15:54 -0400 (EDT) |
| |
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/
| |