From owner-freebsd-current Sun Feb 24 22:11:39 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A042337B404 for ; Sun, 24 Feb 2002 22:11:34 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1P6BXp46367; Sun, 24 Feb 2002 22:11:33 -0800 (PST) (envelope-from dillon) Date: Sun, 24 Feb 2002 22:11:33 -0800 (PST) From: Matthew Dillon Message-Id: <200202250611.g1P6BXp46367@apollo.backplane.com> To: Jake Burkholder Cc: current@FreeBSD.ORG Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assembly revamp, please review! References: <20020224131027.I31343-100000@gamplex.bde.org> <200202241912.g1OJCMx95238@apollo.backplane.com> <20020224224927.D35990@locore.ca> <200202250503.g1P53rd29132@apollo.backplane.com> <20020225010031.A43767@locore.ca> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> :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). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message