Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: Measured overhead of timer interrupts | Date | Fri, 23 Jul 1999 18:56:06 -0400 (EDT) |
| |
Andi Kleen writes: > On Fri, Jul 23, 1999 at 05:16:45AM +0200, Albert D. Cahalan wrote: >> Andi Kleen writes:
>>> This is not really true. There are new columns or lines added to /proc >>> files, but old ones are not changes, and correctly writen /proc parsers >>> should not break (unfortunately there are lots of incorrectly writen >>> proc parser around..) >> >> I know this is not true. I wrote the new ps. (prepare for rant) >> There is no way to write a parser that will survive all of: >> >> 1. new columns > > It is handleable.
No, your example was very simplistic. Consider:
foo_bar wert bar_baz asdf baz_bum spam
This may become:
foo_bar wert 1 bar_baz asdf 2 baz_bum spam 3
It may also become:
foo bar wert bar baz asdf baz bum spam
>> 2. new spelling for keywords or row names > > That is simply a bug and should never happen.
Well, it happens often enough.
>> 3. new rows > > New rows are easy. You have to deal with them all the times.
This means you can not tell where you are by counting, which means that you must have row headers with well-defined spelling and syntax. Well, you don't have that. See /proc/cpuinfo for a great example. See /proc/*/stat for another.
This whole argument wouldn't even exist without the stupid idea of having the kernel produce formatted output. The _kernel_ (!!!) screws around with sprintf(), then system software has to hack at the output with ad-hoc parsers. Gross!
- 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/
| |