From mboxrd@z Thu Jan 1 00:00:00 1970 From: "pradeep singh" <2500.pradeep@gmail.com> Subject: Re: Why can't we sleep in an ISR? Date: Tue, 15 May 2007 15:16:47 +0530 Message-ID: <366312910705150246r356fa97cv96ccbf51779309cd@mail.gmail.com> References: <20070515093423.1150.qmail@webmail81.rediffmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_159383_12638171.1179222407269" Return-path: DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=KTbWeKE8sdwD9w6WHgoaxF6fbTcFAN4DLd55AGD6Tft3H9f19FVMwcLg6i3AHFfdOlo3Mvg5dHf3PWEL3bMGqpTb20cmf+XvrdelYb23P4GcaZkKqNKU+X+c4kDr1LBf38Mi3rTKeu/8wyLoRwD7z1uTXwquENL6NGfDFJUrxsI= In-Reply-To: <20070515093423.1150.qmail@webmail81.rediffmail.com> Sender: kernelnewbies-bounce@nl.linux.org Errors-to: kernelnewbies-bounce@nl.linux.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: List-subscribe: List-owner: List-post: List-archive: To: rohit hooda Cc: Learning Linux , kernelnewbies@nl.linux.org, linux-newbie@vger.kernel.org, linux-kernel@vger.kernel.org, Bahadir Balban ------=_Part_159383_12638171.1179222407269 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 15 May 2007 09:34:23 -0000, rohit hooda wrote: > > > > > On Tue, 15 May 2007 pradeep singh wrote : > >On 5/14/07, Bahadir Balban wrote: > >> > >>On 5/14/07, Learning Linux 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. > Ok, that explains a bit. 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 > > > [image: Peanuts] -- play the game ------=_Part_159383_12638171.1179222407269 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 15 May 2007 09:34:23 -0000, rohit hooda <rohit13hooda@rediffmail.com> wrote:

 


On Tue, 15 May 2007 pradeep singh wrote :
>On 5/14/07, Bahadir Balban < bahadir.balban@gmail.com> wrote:
>>
>>On 5/14/07, Learning Linux <learninglinux4@gmail.com > 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.

Ok, that explains a bit.
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



Peanuts



--
play the game ------=_Part_159383_12638171.1179222407269-- -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ