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