Hey, hornswoggle David J. Brown into hiring me back and I'll do ABI migration and mutation for everybody.
Joking aside, there's a classic discussion of managing both stability and controlled change at http://multicians.org/stachour.html Paul Stachour's "Observations about Software Maintenance" (which I typed in (;-)) --dave Brendan Gregg - Sun Microsystems wrote: > 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 <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' > > 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 > -- 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, bridge: (877) 385-4099 code: 506 9191# _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
