: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.

   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

   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.


                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to