On Tue, Apr 7, 2009 at 5:09 PM, Dan Price <d...@eng.sun.com> wrote: > 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
I can modify these to match the current ARC stability levels. I was hoping to get more comment, but if not, I'm willing to write up the fast-track template with those changes if there's an ARC member that'll submit the case. _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
