running in interrupt context when there's no interrupt raised

running in interrupt context when there's no interrupt raised

Post by Arun Pras » Sun, 24 Nov 2002 11:08:18



Hello,

  I'd like to force my kernel module to run at interrupt context at
some specific points/time and then come back from interrrupt contex
after executing that particular portion of code..

  Is it possible?
  If so, how to achieve this.

  Have a nice time
Warm Regards
Arun

 
 
 

running in interrupt context when there's no interrupt raised

Post by Steven Rosted » Sun, 24 Nov 2002 14:54:14



> Hello,

>   I'd like to force my kernel module to run at interrupt context at
> some specific points/time and then come back from interrrupt contex
> after executing that particular portion of code..

>   Is it possible?

yes

Quote:>   If so, how to achieve this.

Sounds like you want to use task queues or tasklets.

There's two queues that run in interrupt contex:
tq_timer and tq_immediate.
tq_timer runs at every clock tick.
tq_immediate runs at either at a time schedule is called or
before returning from a system call.

tasklets are like interrupt bottom halves but multiple
tasklets my run on two CPUs although never the same tasklet.

-- Steve

 
 
 

running in interrupt context when there's no interrupt raised

Post by Arun Pras » Mon, 25 Nov 2002 07:31:26


Hello,

<<Sounds like you want to use task queues or tasklets.

Quote:>>Yes. That's one part. And the other part is simulate interrupts (

infact simulating the entire hardware behaviour of a PCI based
controller).

<<There's two queues that run in interrupt contex:
tq_timer and tq_immediate.
tq_timer runs at every clock tick.
tq_immediate runs at either at a time schedule is called or
before returning from a system call.

tasklets are like interrupt bottom halves but multiple
tasklets my run on two CPUs although never the same tasklet.

Quote:>>Did you mean there's no difference between the code runs in the ISR

and the code runs in tasklets or bottom halves?
Did you mean they both are having same previleges and restrictions?

Warm Regards
Arun

 
 
 

running in interrupt context when there's no interrupt raised

Post by Steven Rosted » Mon, 25 Nov 2002 08:53:44



>Yes. That's one part. And the other part is simulate interrupts (
> infact simulating the entire hardware behaviour of a PCI based
> controller).

Simulating an actual interrupt is a little different. When the CPU takes
an interrupt, (depending on arch) it invokes some code set up previously
by the initialization code (intel has Interrupt Descriptors, PPC has
vectors, and so on) All these eventually call a function do_IRQ that's
usually in arch/<arch>/kernel/irq.c.  This function calls a get_irq
(at least in PPC it does) which is dependent on what board you're
running on. It returns the IRQ that went off. Then the appropiate
handler is called. That's the function that gets registered with
request_irq.

Quote:> Did you mean there's no difference between the code runs in the ISR
> and the code runs in tasklets or bottom halves?

The code in the ISR (I prefer to call top-half) needs to get in and out
as soon as possible since nothing else is serviced while in a top half.
That's not necessarily true, since a request_irq without the
SA_INTERRUPT flag, will turn interrupts back on.

Quote:> Did you mean they both are having same previleges and restrictions?

All of the kernel code has the same privileges. But as for the
restrictions, yes, the bottom-halves have the same restrictions as
top-halves, except interrupts are on when they start. Those restrictions
are, can't schedule, can't access user space, and anything else that
might call the previous two.

-- Steve