Date: Mon, 20 Mar 2000 18:56:19 -0700 From: Warner Losh <imp@village.org> To: Wes Peters <wes@softweyr.com> Cc: Guido van Rooij <guido@gvr.org>, hackers@FreeBSD.ORG Subject: Re: splFoo() question Message-ID: <200003210156.SAA19697@harmony.village.org> In-Reply-To: Your message of "Mon, 20 Mar 2000 17:44:27 MST." <38D6C5EB.E96A6514@softweyr.com> References: <38D6C5EB.E96A6514@softweyr.com> <20000320210008.A59405@gvr.gvr.org> <200003182031.NAA97975@harmony.village.org> <200003202057.NAA17486@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003210156.SAA19697>