: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:
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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message