:>     *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.  That is, while
    it would be nice to support concurrent operation in that case, the
    current model can't, and the customer can simply rearrange his PCI cards
    if two high-volume devices wind up on the same interrupt to get around
    the limitation.  So making this work would be a very low priority relative
    to other bullets.

                                        -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