On Wed, Sep 16, 2009 at 5:46 AM, Jason King <ja...@ansipunx.net> wrote: > Being distracted by other things for the past few months, I'd like to > get moving on this again and try to get it knocked out. > > To recap, the idea is to associate stability levels to kstats > analogous to the stability levels assigned to dtrace probes. > > Defined stability levels: > KSTAT_STABILITY_PRIVATE > KSTAT_STABILITY_VOLATILE > KSTAT_STABILITY_UNCOMITTED > KSTAT_STABILITY_COMITTED > > The current intention is to repurpose the ks_resv field of kstat_t to > hold this data. > > > The outstanding questions I'd like to try to get some feedback (and > hopeful closure) on (and a +1 for eventual submission of an ARC case):
I said this last time it came up, but I'm strongly against this. It's a lot of work, and I see no benefit to doing it this way. > - Should the stability of the kstat name (i.e. it's existance) be > separate from the data it's presenting (i.e. there should each have > it's own stability)? Pretty much everything matters. The name, the way instances are assigned (and sometimes the meaning of the instance), the names of individual statistics, the list of available statistics, and the actual meaning of the statistics. (The class ought to as well, but it's not been well used.) It's not possible to do this with a single field that only takes 4 values. (And, really, it's a binary switch - either you're free to use it or you aren't.) > - How should the kstat be assigned the stability value? > Options: > 1. A new function is called to set it after kstat_create and > before kstat_install, kstats that don't do this will default to > KSTAT_STABILITY_PRIVATE. Thus bumping up the stability level will > require source code changes. > 2. The existing kstat_create could be extended to add the > info. The downside is that I expect it would be messy -- the current > flags parameter is uchar_t, so it doesn't leave much room for > expansion. A bit could be set to signal the existence of an > additional function argument, but that might get a bit messy in terms > of the impact on the source > 3. A new function is created that would be used in lieu of > kstat_create that includes an explicit parameter for the stability. > Kstats whose stability is something other than private must use this > function (those that are private could use it or the existing > kstat_create). It doesn't belong in the code, and all the above are ugly. It's much better to do this in documentation. (That's how the stability of most of Solaris is described.) This has significant advantages: - No code changes required - Can include changes and history - Can be as coarse or as fine-grained as required - Can include meaning, to guide consumers > - What would the process be to increase the stability of a given > kstat? I suspect some sort of ARC review, but then this gets outside > of my realm of experience. I suspect a few emails to opensolaris-arc > or such might prove useful, though I'm not sure if now is the > appropriate time or not. I'll talk offline to a couple of people and > see what they recommend. Kstats aren't really any different to other interfaces, which go through ARC. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
