On Fri, Feb 13, 2009 at 3:53 PM, Richard Lowe <richl...@richlowe.net> wrote: > Jason King <ja...@ansipunx.net> writes: > >> On Fri, Feb 13, 2009 at 3:12 PM, Brendan Gregg - Sun Microsystems >> <bren...@sun.com> wrote: >>> On Fri, Feb 13, 2009 at 08:09:52PM +0000, Peter Tribble wrote: >>>> On Fri, Feb 13, 2009 at 12:26 AM, Brendan Gregg - Sun Microsystems >>>> <bren...@sun.com> wrote: >>>> > >>>> > No. Stop. Do not assume any data is better than no data. Wrong or >>>> > misleading >>>> > data is *worse* than no data. >>>> >>>> Well, that's not *entirely* true. Senior management isn't satisfied >>>> with no data, >>>> and prefer simplistic data that they're familiar with - even if we >>>> know that it's >>>> wrong or misleading. >>> >>> I think the problem here is one of thinking like an end-user, rather than >>> an engineer. In OpenSolaris, we can engineer whatever is needed - we don't >>> need to make-do with what engineers give us - we are the engineers. >> >> 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, >> even if it has to be unbundled because *gasp* it might happen to use >> say 20 different kstats and Sun won't allow something that uses kstats >> that they didn't write to be putback in any consolidation). > > I think this has to be based on a misunderstanding on somebody's part, > though I don't know whose. > > The above is just not how the interface taxonomy works (not least > because authorship means absolutely nothing in that regard).
In _theory_, authorship is irrlevent, in _practice_, it is. This is simply because Sun is still firmly in control of what gets putback to anything Opensolaris related, and individuals and groups within the company have shown they will leverage that control to bend the rules. Not to get offtrack too much, but as an example (not performance related -- but where authorship controls what is putback) -- look at the ce driver. Not open source no plans to make it open source, but programming specs are open source and other platforms have successfully used the docs to create drivers with no apparent problems (technically or legally). I believe the driver is also not bundled with Opensolaris and has to be downloaded separately. As a learning experience, me and Steven Stallion decided to write a clean-room implementation of it that would be CDDLed. While it was not done to discourage us (since we're doing it for the experience of doing it, what ultimately happens to the driver is a secondary concern over getting it working), me and Steven Stallion were told it will _never_ be putback into any Opensolaris consolidation, even if it were perfect in every possible way (not that I'd claim it would ever approach that) solely because of one group within Sun _will_ prevent it's putback into any consolidation that is managed by a Sun employee. In theory, this shouldn't happen, if it meets all the technical requirements for inclusion, it should go in and Sun should merely in it's distros use it's own closed source version, leaving other distros free to use the bundled one if they wish. So we're left with a bunch of stats, some of which are quite useful, but all are classified as unstable, no apparent way of being able to selectively upgrade the stability of select stats (short of a potentially large separate project along the lines that Brendan suggested), and any attempt to use then without that basically being shotdown for inclusion with Opensolaris because of authorship (Sun can write mpstat and iostat and fsstat and vmstat which all use kstats, but anyone else -- no -- those are unstable, don't touch!). _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
