On Fri, Feb 13, 2009 at 2:48 PM, David Collier-Brown <dav...@sun.com> 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' _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
