Date: Wed, 23 Apr 1997 11:57:14 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: joerg_wunsch@uriah.heep.sax.de Cc: hackers@freebsd.org Subject: Re: concurrent calls to device drivers Message-ID: <199704230227.LAA18664@genesis.atrad.adelaide.edu.au> In-Reply-To: <19970422214531.BX39690@uriah.heep.sax.de> from J Wunsch at "Apr 22, 97 09:45:31 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
J Wunsch stands accused of saying:
> >
> > s = splfoo();
> > while(sc->sc_busy) {
>
> What's the splfoo() for?
>
> Unless the interrupt service can modify sc_busy, you don't need to
> protect it.
I was thinking explicitly about the speaker driver when I wrote this; in
particular I was thinking that, presuming I get around to actually
doing what I had planned, it would take the data from the first
caller, and return as soon as it had buffered everything that was offered
to it.
Other writers would still be sleeping on the busy flag, but then further
down the sample my mind wandered 8)
> You gotta do a
>
> obtain_mp_lock();
> while(sc->sc_busy) {
> ...
> }
> release_mp_lock();
>
> however. :-) On a uniprocessor however, only one process can be in
> the kernel at a time.
Do we have sample implementations of these primitives? Last I heard the
SMP kernel wasn't doing kernel reentrancy yet, so I guess it's not vital
yet...
--
]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
]] Genesis Software genesis@gsoft.com.au [[
]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[
]] realtime instrument control. (ph) +61-8-8267-3493 [[
]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704230227.LAA18664>