On Wed, Sep 16, 2009 at 5:18 PM, Peter Tribble <peter.trib...@gmail.com> wrote:
> 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.
That I suspect would become an ARC issue. If it's treated as a single
unit, then the level of change is at that level -- any change to any
piece would need to follow the stability guidelines (or create a new
stat), and is there really any advantage to allowing that level of
flexibility?
>
> (And, really, it's a binary switch - either you're free to use it or
> you aren't.)
Not necessairly -- just like interfaces it would be guidance as to
when the meaning of the kstat (or even it's existance) might change.
Technically anything can use kstats today (are you're very aware, 3rd
party software uses kstats today, just at it's own risk that any patch
or phase of the moon might break things).
>
>> - 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
Someone else suggested this as well, and I'm not opposed to that
either -- my main goal is to just get to a point where I can file an
ARC case asking 'can kstats X,Y,Z be changed to something !PRIVATE
(such as uncomitted) in order for a subsequent project (perfmib) to
take advantage of them, and have a high degree of confidence it'll be
approved.
The consensus was that something like this needed to happen first.
The alternative of course is that perfmib could always live outside of
an OpenSolaris distro, though that seems a bit silly and potentially a
source of anti opensolaris FUD ('look, you can't even do the most
basic performance monitoring with SNMP without outside software') --
ideally I think it should live either in ON or in the same
consolidation as net-snmp (SFW IIRC, but not 100% sure), so I just
want to clear any hurdles to making that happen.
>
>> - 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
