On Tue 07 Apr 2009 at 02:25PM, Jason King wrote:
> To get around the hurdle of all kstats being effectively private,
> which in turn makes it difficult to effectively build any sort of
> tools that use them, I'm proposing adding stability attributes to
> kstats, similar to how dtrace providers have stability attributes. (I
> believe this was originally suggested by Dan Price, though I'd have to
> look -- the point is I don't want to falsely take credit for the
> idea).
Jason,
This idea has been in the wind for a long time. I ought not get credit
for it :) Credit should go to the person who does the work to realize the idea.
> Stability attributes:
>
> The thinking is unless there's a good reason to diverge, for
> consistency (and sanity of someone trying to figure out what to use),
> I think keeping it analogous to the dtrace attributes makes the most
> sense:
>
> typedef uint8_t kstat_stability_t;
>
> KSTAT_STABILITY_INTERNAL internal to kstat system
> KSTAT_STABILITY_PRIVATE private to ON, the default for all kstats
> KSTAT_STABILITY_OBSOLETE scheduled for removal
> KSTAT_STABILITY_EXTERNAL maintained by a 3rd party
> KSTAT_STABILITY_UNSTABLE new or rapidly changing
> KSTAT_STABILITY_EVOLVING less rapidly changing
> KSTAT_STABILITY_STABLE mature interface
> KSTAT_STABILITY_STANDARD industry standard
> KSTAT_STABILITY_MAX maximum valid stability
I'm sure they will chime in but, at least from a PSARC perspective,
in recent years some of these stability levels have been collapsed
together. I'm not an expert on the theory of the old or the new
taxonomies, but IIRC, in the newer classification, there would
be COMMITTED which I think would swallow up at least EVOLVING,
STABLE, and STANDARD.
But, as you point out, DTrace uses the older taxonomy. Hopefully
others will have perspective for you.
-dp
--
Daniel Price, Solaris Kernel Engineering http://blogs.sun.com/dp
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
