On Tue, 15 May 2007 pradeep singh wrote :
>On 5/14/07, Bahadir Balban < bahadir.balban@xxxxxxxxx> wrote:
>>
>>On 5/14/07, Learning Linux <learninglinux4@xxxxxxxxx > wrote:
>> > Ok, but how about an ISR, that does not take any locks? Why can't we
>> > sleep in SUCH an ISR?
>> > LL
>> > -
>>
>>The killer reason why you can't sleep in an interrupt is because an
>>interrupt is not associated with any context in the first place.
>
>
>good enough, but i have a query regarding this then.
>On a 8K kernel stack system, doesn't interrupts share the stack associated
>with the current process which was interrupted?
Yes, you are right.
>Doesn't interrupt steals the CPU slice time allocated to the running process
>to run?
Yes
>Doesn't it run in current process's context ?
You got it worng here. It runs on behalf of the process, but in the current process's context.
For interrupts we have a dirrerent context altogether.
how will you define an interrupt context?
Thanks
~psr
>
>What am i missing here?
There are two different contexts of execution
Process context
Interrupt context
>
>Thanks
>~psr
>
Thanks,
-Rohit
>What
>>is a context, then? It is the state information for a process. This
>>includes the kernel and userspace stack pointers, the register set,
>>and the page tables for that process. The scheduler has access to all
>>this information, to preempt one process and run another. Contrary to
>>this, an interrupt, depending on the version of your kernel and arch,
>>uses a separate irq stack or the kernel stack of the interrupted
>>process. An irq is not a context but merely a temporary execution to
>>be concluded asap.
>>
>>Hope this helps,
>>Bahadir
>>
>
>
>
>-- play the game
--
play the game
