:On 28-Feb-02 Matthew Dillon wrote:
:>     Not to put too fine a point on it, but, I don't see how this can
:>     possibly justify preventing me from committing my critical_*() stuff.
:>     You've just stated publically that your preemption stuff is unusable
:>     as it currently stands.  Why am I supposed to wait an arbitrary period
:>     of time for you to fix, test, and commit it?
:>     I would REALLY like to commit my critical_*() stuff, and for the record
:>     this will also include the stage-2 stuff described in the original commit
:>     comments that will be made a few days after the current commit.
:Because the critical_* changes you are doing don't match up to the overall
:design.  See my mail to -arch for more on that though.  At some point in the
:future I think that this work can fit in rather well to the cpu_critical_foo
:stuff (which can be split out from critical_enter/exit now).  However, at this
:stage I would rather avoid complex optimizations of APIs that may change in the
:future.  There is more to be gained from locking subsystems.
:John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
:"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

    I strongly disagree.  I have yet to see any technical description of
    this so-called overall design that shows any incompatibility, and what
    I decide to do with my time is my business.  I don't really care 
    whether you are ready for 'optimizations' or not.  I seem to recall
    that you had similar objections when I started pushing Giant into the
    system calls, yet that work is in hind sight an obvious enabler for 
    other work people have been doing and committing.  

    I decided to address a serious issue that I've had with those routines 
    for months because you consistently refused to even entertain the
    notion that you may have constructed the API wrong.  Frankly, I feel
    that these changes both optimize and properly abstract the critical_*()
    code.  I strongly believe that the abstraction you have in there now is
    improper.  My patches have been tested, they work, and they ARE going to
    be committed as soon as I am able to do so.  I believe you are 
    overstepping your bounds as a committer by attempting to scrap them
    and I also believe that you do not fully understand the implications
    of the code, because you are blinded by the notion that I am making 
    adjustments to your API.  But I do, BDE does, Julian does, as do others.

    To me these changes are essential, and they must go in now before
    even more hacks are committed to the codebase to get around existing
    limitations.  There are already hacks in the trampoline/fork_exit
    and ast code that seriously pollutes the MD/MI boundry, all of which
    you've flicked off your shoulder and explained away as being allowed
    by your API, and Peter added a third hack with his pmap commit (which
    got backed-out when he backed out the commit).  These hacks make it
    crystal clear to me that you critical_*()/cpu_critical*() API is 
    seriously flawed.  I am addressing the issue and cleaning up the hacks
    to create a proper MD/MI separation of the code.

    It makes no sense whatsoever to me to be told not to commit something
    due to stale code that may not be quite compatible sitting in P4 that
    you can't make work in any reasonable time frame.  You should stop
    trying to screw over my work and instead look to your own.   You have
    so many balls in the air constructed in a fine mesh that you can't seem
    to accept a single change to your perfectly meshing subsystems, half
    of which are going stale in P4.  This is greatly restricting your
    ability to consider deviation.

    I will repeat, if you want to discuss specific technical issues related
    to these commits after I put them in, I am all ears.  I will repeat, I
    see nothing in this code that prevents you from accomplishing anything
    that you've brought up to date (which so far as just been the non-working
    preemption code you have sitting in P4).

                                        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