On Fri, Feb 13, 2009 at 3:45 PM, Dan Price <d...@eng.sun.com> wrote: > On Fri 13 Feb 2009 at 03:32PM, Jason King wrote: >> >> I would like the think that, all the (summarized) 'never use any >> kstats -- those are private' emails I'm getting off list, as well as >> past reactions I've seen seem to suggest otherwise (not that I'm >> really going to let it stop things -- I'd rather have a good tool, > > I don't know if you're going to get any one voice which is "Sun" > here. If I was to attack this problem, I would, as Brendan suggests: > > - Create mechanism for expressing kstat metadata, and for > querying said mechanism. I would expect this, if properly > architected, to be non-controversial. The DTrace stability > mechanism was not particularly controversial when ARC > considered it in the DTrace case. The trick is nailing > down the different attributes of stability and ancillary > information needed by the consumer. (Stability of name of > kstat. Stability of its type. Stability of its semantic > meaning. Whether said kstat is virtualized for zones or not. > Maybe others). > > - Select kstats to raise above "private" and run ARC cases to > promote the stability level. This creates a commitment-- > which in some cases is probably fine, and in some cases > may not be. > > Properly architected, a proposal of this nature would get my support. > It's not a trivial project, to be sure.
Let's do it. I think the performance and/or observability communites would be appropriate sponsors (please chime in if anyone disagrees). Would we want to be more generic and make the goal a generic annotation feature to kstats (of which stability attributes would be one sort of annotation), or stay strictly with stability annotations (I'm not sure one is any more or less difficult than the other)? _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
