On Fri, 13 Feb 2009, James Carlson wrote:
> [Omitted the PSARC list intentionally.]
>
> Randy Fishel writes:
> > I am sponsoring this case for Rafael Vanoni and Aubrey Li. It proposes
> > a kstat module for observing turbo mode on Intel processors. It proposes
> > a micro/patch binding and a commited module. I believe that this case
> > qualifies as a self-review, should someone request, it can be turned
> > into a fasttrack.
>
> After looking through this case, I'd like to offer a minor suggestion.
> Go ahead and add kstats as debug and service tools any time you want,
> and don't worry too much about ARC review, even as self review.
> _Most_ of them are not intended as stable interfaces.
>
> If you do have a specific consumer in mind (a GUI or some such), then
> feel free to go through ARC review to establish the usage at a higher
> commitment level, but you shouldn't in general have to do too much of
> this.
>
I also questioned if it needed a review, but discussed it with Gary
beforehand. Result was "self-review is easy enough, just go ahead and
do it".
I believe the main reason was the possibility of consumers. As PM
observability is becoming a big thing, we have been describing how to
do it in email lists, blogs, web sites, etc., such that there is some
expectation of implied committment. We are walking the fine line
between debugging evolving work and stable mechanisms for users to see
what is going on. So maybe the better long-term answer is to just add
observability items, and if in the future they show consistant value
to users they can be promoted (could make some of the suspend/resume
observability easy to work with).
Thanks for the comments, and giving me a better viewpoint!
---- Randy
