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