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

Alfred Perlstein 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:
>> 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


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.

-Alfred

-Alfred


More information about the freebsd-arch mailing list