: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

    Huh?  I have made no API changes that have any effect whatsoever on
    these architectures.  Jake is free to implement whatever he wants for
    them, all I intend to do is make it easier and more flexible to do so.
    Sure, I intend to move critical_enter() and critical_exit() from MI to
    MD, but all that means for non-i386 architectures is that the EXACT
    procedures for critical_enter() and critical_exit() now sitting in
    kern/kern_switch.c will be copied into <arch>/<arch>/critical.c.  That's
    the only effect for these other architectures.

    How our architectures handle things like deferred interrupts and SWI
    is architecture specific.  It always has been and always will be.  That
    doesn't mean we have to duplicate a large piece of code in
    <arch>/<arch>/critical.c (for example, SWI handling or deferred 
    context switch support), it simply means that these functions will be
    written in an MI section and the MD critical_*() functions will simply
    call the MI functions.  

    This work will come to a grand total of 2 or 4 lines of code per
    architecture.  Big fucking deal!

                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

:I don't pretend to understand all the issues here, but I think it's
:important to recognize that there have been several coherrent responses to
:the current patch that do need to be addressed.  I think the preference
:I've seen from a number of developers is that the be addressed before the
:commit, rather than after. 
:Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
:[EMAIL PROTECTED]      NAI Labs, Safeport Network Services

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

Reply via email to