Date: Mon, 20 Mar 2000 18:46:01 -0700 (MST) From: Nate Williams <nate@yogotech.com> To: Wes Peters <wes@softweyr.com> Cc: Warner Losh <imp@village.org>, Guido van Rooij <guido@gvr.org>, hackers@FreeBSD.ORG Subject: Re: splFoo() question Message-ID: <200003210146.SAA17825@nomad.yogotech.com> In-Reply-To: <38D6C5EB.E96A6514@softweyr.com> References: <20000320210008.A59405@gvr.gvr.org> <200003182031.NAA97975@harmony.village.org> <200003202057.NAA17486@harmony.village.org> <38D6C5EB.E96A6514@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > : 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. The only concern I can see is that currently it requires you to get too cozy with the machine independant code. Basically, the 'resource' that you want to lock on is the IRQ, and the raw IRQ code is quite machine dependant. Nate 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?200003210146.SAA17825>