Apparently, On Sun, Feb 24, 2002 at 09:03:53PM -0800,
        Matthew Dillon said words to the effect of;

> :...
> :interrupts; hard interrupts are rarely masked.  The queueing is written
> :in assmebler and runs outside of the kernel so it is fast.  Traps in
> :general are fast because they don't touch memory until the trapframe
> :is written out, so I don't see much point in changing this do the masking
> :in software and avoid the soft interrupt.
>     I have no idea what you are talking about Jake.  Could you supply
>     some context?

Sorry, maybe I got ahead of myself.  I was responding to your suggestion
that other architectures should pick up this design.  This does not make
sense for sparc64.

> :In regards to the patch I think that making critical_enter/exit MD in
> :certain cases is a mistake.  cpu_critical_enter/exit are already MD
> :and it looks you could hide this behind them with some minor changes.
> :
> :Like in the critical_enter case, make cpu_critical_enter take a thread
> :as its argument.  It could be a null macro in the i386 case, which would
> :optimize out the test.
> :
> :if (td->td_critnest == 0)
> :     cpu_critical_enter(td);
> :td->td_critnest++;
> :
> :Likewise with cpu_critical_exit, make it take the thread as its argument.
> :
> :If (td->td_critnest == 1) {
> :     td->td_critnest = 0;
> :     cpu_critical_exit(td);
> :} else
> :     td->td_critnest--;
> :(This is equivalent to if (--td->td_critnest == 0), its a matter of taste.)
>     I'm afraid I have to strongly disagree.  I believe that 
>     critical_enter()/exit is *ALREADY* being severely misused in current.
>     For example, fork_exit() makes assumptions about the underlying hardware
>     in order to initialize td_critnest and the scheduler mutex safely.  This
>     is just plain broken.  fork_exit() should not make any such assumptions.
>     It is the clear responsibility of either the trampoline code or
>     cpu_fork() to properly set up td_critnest.  One can make an argument
>     that the sched_lock fixup is in fork_exit()'s domain but you cannot
>     make the argument that the initialization of critnest (and any associated
>     hardware state) is MI.  It just isn't.
>     Additionally, critical_enter()/exit themselves are certainly much
>     more MD then MI.  It makes little sense to abstract out an MI interface
>     that forces unnecessary overhead when all you have to do is define an
>     MD API that has a few MI requirements, like td_critnest being a critical
>     nesting count that the MI code can count on.  But as MI code the existing
>     critical_enter()/exit impose additional MD fields and do not give the
>     MD code the option of not using them (except in a degenerate fashion).
>     Specifically, the use of the td_savecrit field is under the partial
>     contorl of the MI code when it shouldn't be, not just in fork_exit()
>     but also in critical_enter() and critical_exit() themselves.
>     The existing critical_enter/exit code is far too abstracted for its
>     low-level purpose and I *WILL* be moving them into MD sections of the
>     system where they belong.  These are really MD routines, not MI routines.

Fine.  As long as their functionality with respect to MI code does not
change I don't care.

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

Reply via email to