cli () + interruptible_sleep_on_timeout () on 2.4

From: Learning Stuff (dude10939_at_yahoo.com)
Date: 08/26/04 

Date: 26 Aug 2004 09:35:06 -0700

Assume 2.4 kernel.

Assume an user space task has to read some data from a device. So it
invokes read system call, which in turn invokes my module's
"wait_for_interrupt_before_proceeding" function.
User space task has to wait for a interrupt before proceeding further.

Here is some dummy code that I have come across, but not sure how this
works.

==============
static wait_queue_head_t my_wait_q;

int my_module_init()
{
   ...
   init_waitqueue_head(&my_wait_q);
   request_irq(my_irq_num, my_isr, 0, "my_dev_name", NULL);
   ...
}

void my_isr(int irq, void *dev_id, struct pt_regs * regs)
{
   /* Some code goes here */
   wake_up_interruptible(&my_wait_q);
}

void wait_for_interrupt_before_proceeding()
{
   unsigned long flags;

   save_flags(flags);
   cli();

   /* Calling task needs to wait for interrupt b4 proceeding */
   interruptible_sleep_on_timeout(&my_wait_q,1*HZ);
   /* ### */

   /* Some code goes here */
   restore_flags(flags);

   return;
}

Could someone please explain why do we need
save_flage-cli-restore-flags calls here?

cli() is supposed to disable all interrupts on all CPUs in the system.
So if wait_for_interrupt_before_proceeding() is called on behalf of a
user space task, all interrupts are disabled by cli() when control
reaches to interruptible_sleep_on_timeout() and thus
interruptible_sleep_on_timeout will not return if my_irq interrupt
occurs.

I think that control will reach at code marked by /* ### */ above,
only if:
1. Interrupt my_irq occurs within 1sec OR
2. after 1sec if no interrupt occurs.
Am I correct?

In above code, interruptible_sleep_on_timeout can only return after
timeout (1sec) because all intrs were already disabled by cli().
Am I correct?

Could someone please explain control flow of above code? I am not sure
how above code works.

and whether is this the correct way and do we really need
save_flage-cli-restore-flags calls here.

Regards

Relevant Pages

  • cli () + interruptible_sleep_on_timeout () in 2.4
    ... which in turn invokes my module's ... User space task has to wait for a interrupt before proceeding further. ... cli() is supposed to disable all interrupts on all CPUs in the system. ...
    (comp.os.linux.embedded)
  • Re: invalidate caches before going into suspend
    ... Spurious interrupt of what kind? ... The only things that could come in would not be non-INT type interrupts, and those aren't affected by CLI. ... Or an APIC error interrupt in the last moment? ...
    (Linux-Kernel)
  • Re: Raise IRQL or clear interrupt
    ... Raise IRQL or cli, which is better, and why? ... When my interrupt routine is called, I can see that IRQL is PASSIVE_LEVEL. ... context switches must NOT happen. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: invalidate caches before going into suspend
    ... Or an APIC error interrupt in the last moment? ... add another cli, and because the failure mode is subtle memory ... Note the original sequence: ... With physical CPU hotplug, ...
    (Linux-Kernel)