From owner-freebsd-current Mon Mar 27 10:23:31 2000 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id A8BF437B52B for ; Mon, 27 Mar 2000 10:23:28 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id NAA07181; Mon, 27 Mar 2000 13:23:15 -0500 (EST) Date: Mon, 27 Mar 2000 13:23:15 -0500 (EST) From: Daniel Eischen To: Matthew Dillon Cc: Nate Williams , nms@otdel-1.org, freebsd-current@FreeBSD.ORG Subject: Re: Is there spinlocks/semaphores available for drivers? In-Reply-To: <200003271753.JAA41782@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message