Date: Wed, 03 Apr 2013 11:15:40 -0700 From: Alfred Perlstein <alfred@ixsystems.com> To: Adrian Chadd <adrian@freebsd.org> Cc: arch@freebsd.org, Gleb Smirnoff <glebius@freebsd.org> Subject: Re: [CFR][CFT] counter(9): new API for faster and raceless counters Message-ID: <515C71CC.3090908@ixsystems.com> In-Reply-To: <CAJ-VmokTa=iNk62_9Weg8B=NMwZq7Z58ySwM%2Bt-ZFGXrU8g8aA@mail.gmail.com> References: <20130401115128.GZ76816@FreeBSD.org> <20130402232606.GC1810@garage.freebsd.pl> <20130403002846.GB15334@onelab2.iet.unipi.it> <20130403100401.GA1349@garage.freebsd.pl> <515C68B5.2010006@ixsystems.com> <CAJ-VmokM=BUO=i2roCivjHc5RW8azhaFqsXM%2B9G_jU7sbkHGTg@mail.gmail.com> <515C6E3A.9020300@ixsystems.com> <CAJ-VmokTa=iNk62_9Weg8B=NMwZq7Z58ySwM%2Bt-ZFGXrU8g8aA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/3/13 11:07 AM, Adrian Chadd wrote: > On 3 April 2013 11:00, Alfred Perlstein <alfred@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?515C71CC.3090908>