title: Effects of calling sleep functions like set_current_state()/wait_event() in a device driver?
body: <p>I am a little confused by how kernel module works after being loaded into kernel, mainly because of the sleep function calls.</p>
  
  <p>Take a character device driver as example, I have seen code like below in read() function that tries to put a 'process' to sleep using <code>set_current_state()</code> (or sometimes, <code>wait_event_interruptible()</code> etc.):</p>
  
  <pre><code>set_current_state(TASK_INTERRUPTIBLE);
  task = current;
  for(;;)
  {
      if(condition)
          break;
      schedule();
  }
  set_current_state(TASK_RUNNING);
  </code></pre>
  
  <p>While in the write function or interrupt handler, they are trying to wakeup read() by setting condition to true like this:</p>
  
  <pre><code>condition = true;
  wake_up_process(task); // -&gt; task was stored inside read() function
  </code></pre>
  
  <p>The questions I have are:</p>
  
  <ol>
  <li><p>Which 'process' does <code>set_current_state()</code> or <code>wait_event_interruptible()</code> put to sleep here? Is it the user space process that calls system call read() or some kernel process that is created to map the user space process?</p></li>
  <li><p>Assume this device driver access is restricted to only one process by set up atomic count in open() function,  and the device driver has no interrupt enabled, what would happen if read() calls wait_event() and there is no other process actually can wake it up? does it get stuck forever (because no interruptible)?</p></li>
  <li><p>What is the difference between using <code>set_current_state()</code> and <code>wait_event()</code> APIs? I have seen different pieces of code using those functions accordingly... any preference on one over the other should I consider?</p></li>
  </ol>