From owner-freebsd-current Mon Mar 27 9:53:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3169437B676 for ; Mon, 27 Mar 2000 09:53:22 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA41782; Mon, 27 Mar 2000 09:53:18 -0800 (PST) (envelope-from dillon) Date: Mon, 27 Mar 2000 09:53:18 -0800 (PST) From: Matthew Dillon Message-Id: <200003271753.JAA41782@apollo.backplane.com> To: Nate Williams Cc: Daniel Eischen , nms@otdel-1.org, freebsd-current@FreeBSD.ORG Subject: Re: Is there spinlocks/semaphores available for drivers? References: <200003271731.JAA41585@apollo.backplane.com> <200003271746.KAA26582@nomad.yogotech.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> :> *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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message