> :> :> *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.
Huh? CardBus cards are *not* slow. PCMCIA cards are, but CardBus is
pretty dang fast.
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
