[CFR][CFT] counter(9): new API for faster and raceless counters

[Adrian Chadd]

On 3 April 2013 11:00, Alfred Perlstein <alfred at ixsystems.com> wrote:

> One thing to note, the CSV format:
> COLNAME1,COLNAME2,COLNAME3
> DATA1,DATA2,DATA3
>
> is vulnerable to problems where a new column will spring into being due to
> loading of a kernel module/driver/something.
>
> Imo it's better to look at XML or some other pseudo-CSV like:
> COLNAME1:DATA1,COLNAME2:DATA2,COLNAME3:DATA3
> so that we are OK with columns springing into existence or leaving.

Only if its parsed badly. :-)

CSV in the above format should be parsed fine, because your parser
should _first_ establish the column->name mapping and use that moving
forward. It just so happens that most people don't bother with that.

But yes. My (vague) plan with libstatfoo or something else was to
convert Sam's tools to use a base system library and then implement
optional data output filters. (Optional because I may not want them
all on my ridiculously slim embedded stuff.) But the general output
(CSV, human-readable) should be there by default.

Hell, if we're going down this path, it's almost worth suggesting that
the tools should only output machine-parsable output and some _other_
tool should translate that into human-readable. But that may be a bit
too radical..


Thanks,


Adrian