On Nov 6, 2007 2:02 PM, William Fretts-Saxton
<William.Fretts.Saxton at sun.com> wrote:
> Peter,
>
> 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.
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?
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.
(As an example, to get network traffic, just filter on :::rbytes64 - but once
I get the list I want other statistics as well.)
> For some reason I think I saw some documentation that said both that
> wild cards are and are not supported, though I can't find either
> reference right now. Any plans to support either of these filters (wild
> cards and per statistic) in the future?
Regular expression matching got added fairly recently. So one version
will have said that it wasn't supported (for the version that introduced
filters) and then one or two versions later it would have had regular
expression support added.
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
