Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Wes Peters writes:
> : > In message <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] http://softweyr.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
