]> git.saurik.com Git - apple/xnu.git/blame - osfmk/man/evc_wait.html
xnu-344.tar.gz
[apple/xnu.git] / osfmk / man / evc_wait.html
CommitLineData
9bccf70c 1<h2>evc_wait</h2>\r<hr>\r<p>\r<strong>System Trap</strong> - Wait for a kernel (device) signalled event.\r<h3>SYNOPSIS</h3>\r<pre>\r<strong>kern_return_t evc_wait</strong>\r <strong>(unsigned int</strong> <var>event</var><strong>);</strong>\r</pre>\r<h3>PARAMETERS</h3>\r<dl>\r<dt> <var>event</var>\r<dd>\r[in scalar] The task local event ID of the kernel event object.\r</dl>\r<h3>DESCRIPTION</h3>\r<p>\rThe <strong>evc_wait</strong> function causes the invoking thread to wait until the\rspecified kernel (device) generated <var>event</var> occurs. Device drivers\r(typically mapped devices intended to be supported by user space\rdrivers) may supply an <var>event</var> service. The <var>event</var> service defines one\ror more <var>event</var> objects, named by task local <var>event</var> IDs. Each of these\r<var>event</var> objects has an associated <var>event</var> count, initially zero. Whenever\rthe associated <var>event</var> occurs (typically a device interrupt), the <var>event</var>\rcount is incremented. If this count is zero when <strong>evc_wait</strong> is called,\rthe calling thread waits for the next <var>event</var> to occur. Only one thread\rmay be waiting for the <var>event</var> to occur. If the count is non-zero when\r<strong>evc_wait</strong> is called, the count is simply decremented without causing\rthe thread to wait. The <var>event</var> count guarantees that no <var>event</var>s are\rlost.\r<h3>NOTES</h3>\r<p>\rThe typical use of this service is within user space device\rdrivers. When a device interrupt occurs, the (in this case, simple)\rkernel device driver would place device status in a shared (with the\ruser device driver) memory window (established by <strong>device_map</strong>) and\rsignal the associated <var>event</var>. The user space device driver would\rnormally be waiting with <strong>evc_wait</strong>. The user thread then wakes,\rprocesses the device status, typically interacting with the device via\rits shared memory window, then waits for the next interrupt.\r<h3>RETURN VALUES</h3>\r<dl>\r<dt> <strong>KERN_NO_SPACE</strong>\r<dd>\rThere is already a thread waiting for this event.\r</dl>\r<h3>RELATED INFORMATION</h3>\r<p>\rFunctions:\r<a href="device_map.html"><strong>device_map</strong></a>.\r