> > One thing I noticed is that the filters might not be fully
> > functional. For example, "cpu_stat::cpu_stat*" filter doesn't return
> > anything and "cpu_stat:::execpgin" retrieves all statistics...not just
> > the "execpgin" ones.
>
> For the first, you would need to call
>
> addFilter("cpu_stat::cpu_stat*", true);
>
> to get it recognized as a regular expression. Otherwise, it's treated as
> a literal.
Ah, thanks!
> Should I make regex the default? There's a performance hit involved
> (which I haven't quantified, so I don't know whether it's crucial). Or try
> and decide whether it's just a plain literal or something more complex?
The only advantage would be for it to behave how one would
expect...like the kstat CLI. On the other hand, if it worked by
default, then I wouldn't have realized the unintended performance
benefit from using a literal. I'd prefer it tuned for performance,
even if it meant straying a bit from the kstat CLI expectation. IMHO,
I'd leave it as is, for now.
> For the second, what is expected to happen is that you get back a list
> of kstats that *contain* the statistic you've specified. When you read them
> you get all the statistics of course. If you're only interested in the
> statistic
> you searched for, then just look up that value. Often, though, what I want
> to do is use the filter to construct the list, and then read lots of
> other values.
Makes sense. I, again, confused retrieving the filter lists of
"statistic-less" kstats with the actual retrieving of the statistics.
I'll get used to it @ some point!
Thanks for the help (again).
-Bill
