:
:> :>     *not* preempted except when being interrupted, so there are no
:> :>     'priorities', per say.  Or, rather, the relative priority is strictly
:> :>     that the interrupt takes priority over supervisor code except when
:> :>     disabled by said supervisor code.
:> :
:> :But locks with owners wouldn't have to disable interrupts (given that
:> :we have interrupt threads).  What about shared interrupts?  You could
:> :still field and process the interrupt as long as it was for a different
:> :device.
:> :Dan Eischen
:> 
:>     The word 'too bad' comes to mind re: shared interrupts.
:
:Too bad is not acceptable.  If we want to support multi-function
:PCMCIA/CardBus cards, we *must* do shared interrupts, and multi-function
:cards are becoming the standard, rather than the exception.
:
:Nate

    First, each PCI slot has *two* assignable interrupts.

    Second, CardBus cards are so slow that you would see absolutely no
    gain in performance whatsoever by being able to run concurrent interrupt
    threads for a single shared interrupt.

    So, frankly, it is perfectly acceptable.  I can't think of a single
    real-life setup that would sufffer.

                                        -Matt
                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>


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

Reply via email to