On Fri, Feb 13, 2009 at 03:07:29PM -0600, Jason King wrote: > On Fri, Feb 13, 2009 at 2:48 PM, David Collier-Brown <[email protected]> wrote: > > I'll see you on the list (;-)) > > > > Back when I was full-time (I'm a contractor > > who does capacity planning), I was part of the > > ABI team, who managed the stable/unstable > > interfaces, so as not to suffer "dll hell" > > like some other folks we all know. > > > > To oversimplify, "private" interfaces which > > change from release to release have to be > > tracked by outside software vendors, and > > they really *really* don't like doing that. > > Imagine being Oracle and having to check that > > all your uses of SUNWprivate interfaces > > still worked whenever you got a new OS release. > > > > There are a few companies who do so, and > > Oracle is (or at least was) one of them, but > > everyone else wants stuff to remain unchanged. > > > > In the case of a mib, which can't check a > > library to see if something is private or not, > > we'll have to set ground-rules so that one > > can introduce new interface names, drop old > > ones and never ever change the meaning of a > > datum without creating a new interface name > > for it. > > Not a small task! > > I understand that. The problem is, it seems Sun has taken the stand > that _all_ kstats are essentially 'private'. Which is fine, but then > there seems to be no way to make _specific_ kstats have a more stable > classification, though even that may not be necessary -- I'd rather > have good useful metrics be what's 'stable' (and what you see in the > MIB) and how they're obtained be an implementation detail. If they > just happen to match up exactly with an existing kstat, well that > makes things much easier, but if that wasn't always the case, I'd > rather change the module to still produce the expected result. > > The problem is, currently the line is '_any_ kstat cannot be used by > anyone (that isn't Sun) for any reason', so with that position, we > kind of go in circles. I.e. we can't say > 'unix:foo:0:really_useful_stat is extremely good to know, and making > what it's measuring available via the perfmib would be good', because > _all_ kstats are effectively off limits. That's why the *stat > commands were chosen as a starting point -- while some of the things > aren't useful, some are, so at least with those that are we can reply > in defence 'we're only doing what XXXXstat is doing, and that command > is unlikely to go away any time soon'
I think a number of us would love kstats to have the same embedded stability semantics that DTrace has for its probes and arguments - that way, we can specify which kstats are stable (and as engineers, keep them stable) and which are not. If I could work on anything I wanted, this would be high on the list. :) Brendan -- Brendan Gregg, Sun Microsystems Fishworks. http://blogs.sun.com/brendan _______________________________________________ perf-discuss mailing list [email protected]
