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

    All I am advocating is that either cpu_fork() or the trampoline code 
    be responsible for setting up the '1 level of critical_enter()' state 
    that fork_exit() is currently hacking together with twine and bailing
    wire.  That seems pretty straightforward to me.  There is a window
    of opportunity between the trampoline code and the point where 
    fork_exit() installs td_critnest where an interrupt can occur and 
    mess things up.  In order to get around this window, fork_exit() is
    making assumptions about the underlying hardware that it should not
    be making.

    For IA32 I will probably fix it in cpu_fork() itself in a later commit
    and not have to touch the trampoline code at all, but for this current
    commit I am fixing it in the trampoline code for i386 and have a
    compatibility shim in fork_exit() for the other architectures.

    I will also be moving critical_enter()/exit() from MI to MD at some
    point (not this commit, some later commit), but for the other 
    architectures it will be the same code.  I am only optmizing i386.

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

    The functionality does not change unless you are making an assumption
    in regards to interrupt disablement vs interrupt deferral in the MI
    code.  Only fork_exit() makes that assumption at the moment but the
    commit will only correct the assumption for I386.  It will not change
    anything for the other architectures (i.e. the assumption can still be
    made for the other architectures).

                                        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