Jason King <ja...@ansipunx.net> wrote:
> 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
Do you have values for PHASING_THIS_OUT and IT_AINT_THERE_ANYMORE?
The latter is mostly for documentation purposes, but phasing things
out is something we occasionally do.
> 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)?
Since the metrics are monads, not composite things, any change
in the data's representation needs to be made known to the
consumers of the data. That pretty much demands the name change,
and so the stability should be on the name and value as a unit.
This makes it a bit easier to manage: if you had a metric
called, fro a contrived example, day_of_week, represented as
0-6 starting with Sunday, and you wanted to introduce a new
metric that was the day of the Sun business week, starting
on Saturday, you could introduce sun_business_day, use it
for a while and then and only then phase out day_of_week.
[Idea and example stolen from Paul Stachour]
> - 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).
Alternately, we could create the new function, say
kstat_create_versioned() and redefine kstat_create() to
be kstat_create_versioned(... ,KSTAT_STABILITY_PRIVATE)
Anyone calling the old function gets the current behavior, and
one could add the add the attributes as a low-priority task over several
builds of Solaris. When you think you're done, one could then locally
#undef kstat_create, get a list of everywhere you need to remove the
old versions and up[date them all.
>
> - 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.
I speculate it would be a fast-tracked ARC case.
--dave (ex-ABI team guy, still around as a contractor) c-b
--
David Collier-Brown | Always do right. This will gratify
Sun Microsystems, Toronto | some people and astonish the rest
dav...@sun.com | -- Mark Twain
cell: (647) 833-9377, home (416) 223-8968, bridge (877) 385-4099 code
506 9191#
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
