From owner-freebsd-hackers Mon Mar 20 22:31:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id F39E037BB05 for ; Mon, 20 Mar 2000 22:31:24 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (Foolstrustidentd@obie.softweyr.com [204.68.178.33]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id XAA05578; Mon, 20 Mar 2000 23:31:14 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <38D7177C.C7DD9BF1@softweyr.com> Date: Mon, 20 Mar 2000 23:32:28 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: Guido van Rooij , hackers@FreeBSD.ORG Subject: Re: splFoo() question References: <38D6C5EB.E96A6514@softweyr.com> <20000320210008.A59405@gvr.gvr.org> <200003182031.NAA97975@harmony.village.org> <200003202057.NAA17486@harmony.village.org> <200003210156.SAA19697@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message <38D6C5EB.E96A6514@softweyr.com> Wes Peters writes: > : > In message <20000320210008.A59405@gvr.gvr.org> Guido van Rooij writes: > : > : perhaps we need some mutex mechanism? > : > > : > Yes. Right now the mutex mechanism that we have is blocking of > : > interrupts when the bit is set in the cpl. I guess I'm a little too > : > close to the mechanism and need to step back. > : > > : > You are right that I'm asking for a call that is approximately "block > : > my interrupt handler from running until I say it is ok." A more > : > generalized mutex/locking scheme is needed so that I can just grab a > : > mutex in my code and in my ISR and the right thing will just happen. > : > : A per-driver mutex, perhaps? This would save us from potential > : deadly embraces within a single driver, at least. > > We kinda sorta have this right now with the interrupt routine being > blocked when the cpl is too high. I'd like to see this more > generalized than it is today. > > However, jumping in and mucking with this code makes me nervous. I'm much more familiar with VxWorks style device drivers, which typically just give a "go" semaphore to an appropriate task that will then perform the actual I/O in a task (think thread) context. It's a different kind of beast from a typical UNIX driver model, but it goes a long way towards avoiding interrupt livelock, since you can balance the priorities of the threads doing the actual I/O. This seems like a good place to point out how much kernel threads would help. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message