[CFR][CFT] counter(9): new API for faster and raceless counters
alfred at ixsystems.com
Wed Apr 3 18:15:54 UTC 2013
On 4/3/13 11:07 AM, Adrian Chadd wrote:
> On 3 April 2013 11:00, Alfred Perlstein <alfred at ixsystems.com> wrote:
>> One thing to note, the CSV format:
>> 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:
>> 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..
You're not hearing me.
How do you xlate sysctl-a when a module being loaded/unloaded can cause
mibs to appear/disappear.
Your choice with the former format is:
1) case where new mib appears -> ignore it
2) case where mib disappears -> give it some absurd value (nul?)
I'm more concerned with #1.
More information about the freebsd-arch