Apparently, On Thu, Mar 07, 2002 at 05:21:21PM -0500,
        Robert Watson said words to the effect of;

> On Thu, 7 Mar 2002, Warner Losh wrote:
> > In message <[EMAIL PROTECTED]> Julian 
>Elischer writes:
> > : 
> > : 
> > : On Thu, 7 Mar 2002, Justin T. Gibbs wrote:
> > : > 
> > : > Then do the right things so it will.
> > : 
> > : Unfortunatly that has been proven to not work.
> > : 
> > : after reverting the change and silently waiting for a week
> > : 1/ no person bothered to review it.
> > : 2/ people assumed the patch had gone away.
> > 
> > Ummm, There are reviews in the archives that object to the API as it
> > relates to optimization and those objections haven't been sanely
> > answered with anything more constructive than "BS". 
> 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.

Bruce also had some comments which were shrugged off, I thought they
were important.  Specifically, please do not make unnecessary changes
to the assembler code.  Macros do not need to be defined before they
are used, I believe this was the justification for some of the reordering
in apic_vector.s which makes the patch confusing.  Please do not tab
out the "; \" at the end of the lines in the INTR and FAST_INTR macros
in icu_vector.s.  This just makes unnecessary diffs.  The PUSH_DUMMY
macro must push a reasonable eip value, in addition to the code segment,
so that profiling and stack traces work right.  If you have not already,
please make sure that a trace from inside an interrupt handler that was
unpended looks somewhat normal.  Please also make sure that kgdb is able
to decode the frame properly.  It assumes that the eip of the frame will
be near certain kernel symbols in order to determine what kind of frame
it is.


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

Reply via email to