On Fri, Feb 13, 2009 at 4:49 PM, Dan Price <d...@eng.sun.com> wrote: > On Fri 13 Feb 2009 at 04:28PM, Jason King wrote: >> 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, > > While IANAL and cannot comment on this specific case (I have and want no > knowledge of it), I will note that people who make claims of this sort, > regardless of employer or field of work, are often wrong. Sometimes we > call it "overcoming organizational antibodies". Sometimes you can, > sometimes you can't.
Oh, we still plan to try :) Worst case it remains unbundled, we've still gained the experience and Sun looks silly for either not including or not opening the driver in Opensolaris that is used in a significant amount of their customer base, and for preventing a perfectly good replacement from being included. So we're not the ones with anything to lose really. But to put the more relevant discussion another way, vmstat, mpstat, iostat all use kstats -- by the "none shall use kstats" 'rule', why are these allowed to exist? Why was fsstat, which is relatively new (I believe it was created post-creation of Opensolaris), and also uses kstats allowed in, while something else potentially going in the same consolidation also using kstats cannot? For the sake of argument, why couldn't something else that used the _exact_ same kstats go in? > > -dp > > -- > Daniel Price, Solaris Kernel Engineering http://blogs.sun.com/dp > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
