On Thu, 7 Mar 2002, Jake Burkholder wrote:

> Apparently, On Thu, Mar 07, 2002 at 05:21:21PM -0500,
>       Robert Watson said words to the effect of;
> > The primary objections I've seen from Jake, and he posted them as part of
> > the earlier thread prior to the commit, was that the API changes proposed
> > by Matt don't make sense for the sparc64 implementation, uni-processor or
> > multi-processor, and that while these changes might be appropriate for
> > i386, he wanted to see the APIs set up in such a way that the differences
> > in architectures were hidden in the MD code.  This suggests working some
> > more on the API before moving on, and my reading of earlier posts in the
> > thread from John was that that was what he had in mind also.
> Yes.  What I would like and what I mentioned before is for this to be
> hidden behind cpu_critical_enter/exit.  Specifically, cpu_critical_enter
> would be a null macro for i386, which would turn critical_enter into
> just an increment, as Matt wanted.  cpu_critical_exit would do all the
> magic of unpending interrupts.  The reason for this is that I would
> like to see critical_exit handled any pending preemptions for a thread.
> We do not yet know exactly how this will work so I would like this to be
> done in MI code to start with.  The code must not make assumptions that are
> not valid on all platforms.  This is easiest if they use the same code.
> This is not about duplication of code in several MD files.

There must be something that disables all interrupts, since fast
interrupt handlers and other very-time-critical code needs to disable
all interrupts.  That something must have an MI interface, and it is
currently named cpu_critical_enter(), so cpu_critical_enter() (or
whatever it is named) must not be null.

Your scheme basically needs another level of criticality between
cpu_critical and plain critical (currently, criticality is not very
hierarchial, but it should be).  This level and the plain level must
not mask fast interrupts (if any), since masking interrupts in
not-very-critical code like the scheduler makes them non-fast.


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

Reply via email to