:You seemed to have missed the entire part where we handle deferred preemptions
:in MI code in critical_exit().  The critical_enter/exit stuff really exists to
:support the preemption code and to get rid of the various FOO_NOSWITCH flags. 
:I think it is ok to remove the linkage between critical_enter/exit and
:cpu_critical_* (possibly even renaming cpu_critical_* to a better name) and to
:allow arch's to optimize cpu_critical_* but leave critical_* as MI code. 
:That's what I've asked for from the start and Jake even suggested it from the
:I'm still not comfortable with the optimiation, but changing the MI critical_*
:code is by far my biggest objection to the code.
:John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/

    Who said anything about not handling deferred preemptions in
    MI code in critical_exit()?  You mean just because I am moving less then
    30 lines of code from MI to MD you object to the concept?  What
    is so difficult about having the code, in the MD source files, do this:

        if (td->whatever_preemption_request) 

    We do this sort of thing all the time in MD code.  It's useful because
    it allows us to focus a critical piece of code in a single source file
    rather then forcing us to split the critical piece of code into three or
    four source files as your current code does... all in the name of placing
    a bare 30 lines of code (less!) in kern/ instead of in <arch>/.../?

    Because in my view that is ALL you are talking about here... I don't see
    why the above code has to be in an MI procedure.  It can just as easily
    be in an MD implementation of critical_*() and I believe the implementation
    of the API is far easier to work with and far more flexible with these
    two procedures sitting in MD rather then MI.

    I don't see how my code can possibly interfere with deferred preemption.
    Two lines of code in <arch> does not constitute interference, and I am
    certainly willing to deal with that myself... you don't have to lift one
    bloody finger.  All you need to do is write your MI preemption handling
    code and you would have to do that in any case.

    Look at all the hacks you ALREADY have to deal with the split you impose 
    between critical_*() and cpu_critical_*().  Look at the hack peter did
    and look at the incorrect assumptions you already have made in MI code
    due to the way you constructed the original API (hard interrupt

    And, most of all, I don't see how something so trivial should result
    in you vetoing my commit.  I mean, it's no skin off your nose if
    down the line it turns out that critical_*() gets complex enough to 
    warrent an MI split, because I would be the one doing it.  But, right
    now, even with the preemption stuff you are talking about, there is NO
    REASON to keep a forced split and plenty of reasons to move it to MD.

                                        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