:This same issue came up at the BSDCon developers conference in
:regard to ithreads. Is it better to optimize some bit of code
:because it is the fun and interesting thing to do, or to build a simple,
:yet stable and easily verified foundation, that we can later optimize
:in a controlled manner? This is not about whether these particular
:changes are correct. The concern is that they may contain a subtle
:bug that makes it difficult to verify other portions of the system.
:...
:--
:Justin
Well now hold on a second here Justin. Did you even look at the
patch? Or are you just making a generalization that is totally
unrelated to the patch? Perhaps you are unaware of the sysctl
instrumentation that allows the interrupts-enabled-during-critical-section
mechanism to be turned on and off on a whim? Perhaps you are unaware
that this patch is not JUST an optmization. Far from it, it solves a
number of what I consider to be critical issues. For example, it
solves the IPI deadlock problem, and it allows us to cleanup some
fairly aweful hacks in the code, e.g. in fork_exit().
I'm all for a discussion, but I would prefer it if the discussion were
based on the actual work that I am trying to get committed and not
some incorrect generalization that is being used to justify some other
approach.
None of this is secret. I've stated these facts very clearly a half
dozen times now AND in the commit message. Don't ignore it or assume
that I am some beginner who's just throwing random commits in and
destabilizing the tree. I have gone to great lengths to do the precise
opposite of that.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
