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):
- 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)?
- 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).
- 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.
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
