On Aug 2, 2011, at 2:31 AM, sheetal phirke wrote: In windows the IRQL at which a driver routine executes determines which kernel-mode driver support routines it can call. e.g. PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL etc.
Do we need to care such interrupt levels in Mac OS? how does it work? Sheetal,
There are a number of different contexts in which driver code can run; these include:
- Interrupt Filter context. This is analagous to DIRQL, though xnu doesn't preempt interrupt handlers, so you should not count on running for a long time at a "low" driver interrupt priority level in your filter.
- Workloop thread context. This is where your regular InterruptEventSource action runs. It's a regular thread with a priority somewhere between normal user threads and realtime threads. It's similar to PASSIVE_LEVEL, but your interrupt is normally masked (you can control this with your filter routine, if required).
- Callout thread context. This is where thread_call and TimerEventSource actions run. This is at a higher priority than the workloop thread, but no interrupts are masked so again, similar to DISPATCH_LEVEl.
- Client thread context. This is where you're running when you receive a call from any of your client-facing interfaces. The priority of these threads can vary widely.
In terms of what you can call; the distinction is largely between the filter context and the regular thread contexts. In filter context you generally don't want to do anything you don't absolutely have to. Talking to your hardware is OK, but it's your responsibility to ensure that you interlock safely with your non-filter-context code. Using IOCommandGate::commandWakeup() is OK, as is using the thread_call APIs to schedule asynchronous threads. Virtually everything else is off limits; the filter's job is to satisfy any immediate needs the hardware has and decide whether the workloop thread needs to be woken. If you find yourself trying to do anything complicated here, chances are good that one or more of your software architecture and your hardware are broken.
From the other contexts, your API options are far wider; most kernel services are safe to call from any thread context, though you should take care if you are talking to other drivers to ensure that you avoid holding more than one workloop lock at a time in order to reduce the likelihood of deadlock.
HTH.
= Mike
-- Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile -- Hippocrates
|