From mboxrd@z Thu Jan 1 00:00:00 1970 From: "rohit hooda" Subject: Re: Why can't we sleep in an ISR? Date: 15 May 2007 09:34:23 -0000 Message-ID: <20070515093423.1150.qmail@webmail81.rediffmail.com> Reply-To: "rohit hooda" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="Next_1179221663---0-202.54.124.237-1119" Return-path: 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: pradeep singh <2500.pradeep@gmail.com> Cc: Learning Linux , kernelnewbies@nl.linux.org, linux-newbie@vger.kernel.org, linux-kernel@vger.kernel.org, Bahadir Balban This is a multipart mime message --Next_1179221663---0-202.54.124.237-1119 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =0A=0A=0AOn Tue, 15 May 2007 pradeep singh wrote :=0A>On 5/14/07, Bahadir= Balban wrote:=0A>>=0A>>On 5/14/07, Learning Lin= ux wrote:=0A>> > Ok, but how about an ISR, that = does not take any locks? Why can't we=0A>> > sleep in SUCH an ISR?=0A>> > L= L=0A>> > -=0A>>=0A>>The killer reason why you can't sleep in an interrupt i= s because an=0A>>interrupt is not associated with any context in the first = place.=0A>=0A>=0A>good enough, but i have a query regarding this then.=0A>O= n a 8K kernel stack system, doesn't interrupts share the stack associated= =0A>with the current process which was interrupted?=0AYes, you are right.= =0A>Doesn't interrupt steals the CPU slice time allocated to the running pr= ocess=0A>to run?=0AYes=0A>Doesn't it run in current process's context ?=0AY= ou got it worng here. It runs on behalf of the process, but in the current = process's context. =0AFor interrupts we have a dirrerent context altogether= .=0A>=0A>What am i missing here?=0AThere are two different contexts of exec= ution=0AProcess context=0AInterrupt context=0A>=0A>Thanks=0A>~psr=0A>=0ATha= nks,=0A-Rohit=0A>What=0A>>is a context, then? It is the state information f= or a process. This=0A>>includes the kernel and userspace stack pointers, th= e register set,=0A>>and the page tables for that process. The scheduler has= access to all=0A>>this information, to preempt one process and run another= . Contrary to=0A>>this, an interrupt, depending on the version of your kern= el and arch,=0A>>uses a separate irq stack or the kernel stack of the inter= rupted=0A>>process. An irq is not a context but merely a temporary executio= n to=0A>>be concluded asap.=0A>>=0A>>Hope this helps,=0A>>Bahadir=0A>>=0A>= =0A>=0A>=0A>-- play the game=0A --Next_1179221663---0-202.54.124.237-1119 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0A 
=0A
=0A
=0AOn Tue, 15 May 2007 pradeep singh wrote :=
=0A>On 5/14/07, Bahadir Balban <bahadir.balban@gmail.com> wrot= e:
=0A>>
=0A>>On 5/14/07, Learning Linux <learninglinu= x4@gmail.com> wrote:
=0A>> > Ok, but how about an ISR, that = does not take any locks? Why can't we
=0A>> > sleep in SUCH an = ISR?
=0A>> > LL
=0A>> > -
=0A>>
=0A>= >The killer reason why you can't sleep in an interrupt is because an
= =0A>>interrupt is not associated with any context in the first place.=
=0A>
=0A>
=0A>good enough, but i have a query regarding = this then.
=0A>On a 8K kernel stack system, doesn't interrupts share = the stack associated
=0A>with the current process which was interrupt= ed?
=0AYes, you are right.
=0A>Doesn't interrupt steals the CPU sl= ice time allocated to the running process
=0A>to run?
=0AYes
= =0A>Doesn't it run in current process's context ?
=0AYou got it worng= here. It runs on behalf of the process, but in the current process's conte= xt.
=0AFor interrupts we have a dirrerent context altogether.
=0A>= ;
=0A>What am i missing here?
=0AThere are two different contexts = of execution
=0AProcess context
=0AInterrupt context
=0A>
= =0A>Thanks
=0A>~psr
=0A>
=0AThanks,
=0A-Rohit
=0A&g= t;What
=0A>>is a context, then? It is the state information for a = process. This
=0A>>includes the kernel and userspace stack pointer= s, the register set,
=0A>>and the page tables for that process. Th= e scheduler has access to all
=0A>>this information, to preempt on= e process and run another. Contrary to
=0A>>this, an interrupt, de= pending on the version of your kernel and arch,
=0A>>uses a separa= te irq stack or the kernel stack of the interrupted
=0A>>process. = An irq is not a context but merely a temporary execution to
=0A>>b= e concluded asap.
=0A>>
=0A>>Hope this helps,
=0A>&= gt;Bahadir
=0A>>
=0A>
=0A>
=0A>
=0A>-- pla= y the game
=0A=0A

=0A

=0A
3D'Peanuts'
--Next_1179221663---0-202.54.124.237-1119-- -- 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