On 5/14/07, Learning Linux <learninglinux4@xxxxxxxxx> wrote:
Adding extra complexity is to be refrained from, because such ISRs are very few IMHO.
Moreover on a SMP system why wouldn't you need a lock? preemption is disabled only on the local processor i guess. CMIIW
Who will preempt you, in this case? i.e to sleep? No one, you will complete and therefore you should be really fast in doing it.
Becasue you have just disabled kernel preemption. In other words ISR is not like any other process waiting to run, it is a special kernel control path which is special because of the reasons you have given.
There is no task struct for your interrupt, no accounting as such AFAIR and etc etc.
It runs in current process's context, isnt it?
HTH
~psr
> > I have a very basic doubt here ... what makes it impossible to sleep
> > in an ISR? I mean, I know that the kernel preemption is disabled and
> > the kernel will panic, but I could not understand why?
>
> Because the interrupt which you are serving in the
> ISR has been masked to avoid preemption(
> true for maskable inetrrupts ).Any locks you are holding in ISR are now with
> you solely. So, if you try to sleep you take the locks you untill you are
> rescheduled and complete. This may lead to
> a deadlock for the lock resource.
Ok, but how about an ISR, that does not take any locks? Why can't we
sleep in SUCH an ISR?
Adding extra complexity is to be refrained from, because such ISRs are very few IMHO.
Moreover on a SMP system why wouldn't you need a lock? preemption is disabled only on the local processor i guess. CMIIW
AFAIK, taking a lock disables kernel preemption, and hence it is not
allowed to sleep. So I think my question would boil down to why is
sleeping not allowed when the kernel preemption is disabled.
Who will preempt you, in this case? i.e to sleep? No one, you will complete and therefore you should be really fast in doing it.
Becasue you have just disabled kernel preemption. In other words ISR is not like any other process waiting to run, it is a special kernel control path which is special because of the reasons you have given.
There is no task struct for your interrupt, no accounting as such AFAIR and etc etc.
It runs in current process's context, isnt it?
HTH
~psr
LL
--
play the game
