You may wish to involve David J Brown, my former boss on the ABI team, and the source of much of the seminal work on stability.
I've CC'd the most likely of the other David Browns at Sun (;-)) --dave From: Jason King <ja...@ansipunx.net> 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). The immediate need is as a prerequisite for the SNMP > performance MIB, so that it can be done right. > > I'd like to throw out a proposed design for discussion (see below). > If a consensus can be reached, then I'd like to create an ARC case for > submission. I'm not sure it's big enough to warrant it's own project > (though if others disagree, I'm fine with that as well). > > 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 > > > Kernel Interfaces: > > int kstat_set_stability(const char *ks_module, const char *ks_name, > kstat_stability_t stability); > Desc: set the kstat to a given stability level > Returns: 0 - success > EINVAL - stability level isn't valid > ENOENT - kstat doesn't exist > > ??: should this be mutable, or should it be allowed to only be set > once, and return an error from there on out? > > int kstat_get_stability(const char *ks_module, const char *ks_name, > kstat_stability_t *stability); > Returns: 0 - stability value in stability. If the stability value was > not explicitly set, *stability contains KSTAT_STABILITY_PRIVATE. > ENOENT - kstat does not exist. > > User interfaces: > > int kstat_get_stability(kstat_ctl_t *kc, const char *ks_module, const > char *ks_name, kstat_stability_t *stability) > Similar to kernel interface > Returns 0 on success, -1 on failure. On failure, errno is set to: > ENOENT - kstat does not exist. > > ??: How should the perl module be updated. -- 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
