On Mon, 27 Mar 2000, Matthew Dillon wrote:
>
> :
> :> :> *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.
And would there still be areas of the kernel that disable multiple
interrupts, perhaps CAM or the network stack for instance? What do
all the splbio and splnet calls translate into in this new scheme?
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
