tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: when can we tsleep() ?



On Thu, Oct 30, 2008 at 2:37 PM, Manuel Bouyer 
<bouyer%antioche.eu.org@localhost> wrote:

> the problem is that in my case, this part of code can be called from different
> context: hardware interrupt, software interrupt, kernel thread or user
> thread. I hoped there would be a simple way to know if tsleep is allowed
> from the code, or if I have to use delay (or return asking to come back from
> a kernel thread). Passing a flag to indicate the context is not so easy in
> my case.
>

I'm dealing with a similar issue: in the [newer] drm code, some card
drivers want to use the linux
'tasklet' facility (on NetBSD, I'm using workqueue(9)).  In the code,
they have this comment:

/*
 * This is intended for triggering actions that require the HW lock from an
 * interrupt handler. The lock will be grabbed ASAP after the interrupt handler
 * completes. Note that the callback may be called from interrupt or process
 * context, it must not make any assumptions about this. Also, the HW lock will
 * be held with the kernel context or any client context.
 */

Note that in this case the "HW lock" is a proprietary structure found
in memory shared
with every OpenGL context, i.e. not an OS-provided lock.  Is there any sane way
to deal with this?

Regards,

--Blair


Home | Main Index | Thread Index | Old Index