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:
- 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.
Thanks,
-dp
--
Daniel Price, Solaris Kernel Engineering http://blogs.sun.com/dp
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
