On Fri, Feb 13, 2009 at 3:45 PM, Dan Price <d...@eng.sun.com> wrote:
> On Fri 13 Feb 2009 at 03:32PM, Jason King wrote:
>>
>> I would like the think that, all the (summarized) 'never use any
>> kstats -- those are private' emails I'm getting off list, as well as
>> past reactions I've seen seem to suggest otherwise (not that I'm
>> really going to let it stop things -- I'd rather have a good tool,
>
> I don't know if you're going to get any one voice which is "Sun"
> here. If I was to attack this problem, I would, as Brendan suggests:
Well given the somewhat contradictory responses I've gotten already
('let's pick the right kstats', 'don't use any kstats') etc, I would
say that is definately the case :)
>
> - Create mechanism for expressing kstat metadata, and for
> querying said mechanism. I would expect this, if properly
> architected, to be non-controversial. The DTrace stability
> mechanism was not particularly controversial when ARC
> considered it in the DTrace case. The trick is nailing
> down the different attributes of stability and ancillary
> information needed by the consumer. (Stability of name of
> kstat. Stability of its type. Stability of its semantic
> meaning. Whether said kstat is virtualized for zones or not.
> Maybe others).
>
> - Select kstats to raise above "private" and run ARC cases to
> promote the stability level. This creates a commitment--
> which in some cases is probably fine, and in some cases
> may not be.
>
> Properly architected, a proposal of this nature would get my support.
> It's not a trivial project, to be sure.
An interesting idea. Maybe that's the way out of this maze.
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
