:
:> :> *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