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 10:47:54 +0530 Message-ID: <366312910705142217geba69dbm98a6c0bf2aabb937@mail.gmail.com> References: <9f1dc2cf0705132337k13aa3ccesc575d4550492a24e@mail.gmail.com> <366312910705140010m78b215a2t1753445e81120288@mail.gmail.com> <9f1dc2cf0705140016w6d8f44f9wec7586e7879af873@mail.gmail.com> <7ac1e90c0705140824i54e1c43ela3ab3d89827c0339@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_157389_2355371.1179206274153" 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=Ue1Ss41EAXCzYjYGy2vLtuYdySVWudqqEsjdoyOSjP9+1jnSjGddEInog4SWjqIrSt/SMTSbXl13YL2CcZTYTzUe9V2ggiD4sHqsbJoblUtZofDJceHwUPBesdGdUiW/R6d3e+Th1LQLKz2uwhjbk2BmmrY/OwpTAABDggX+/HE= In-Reply-To: <7ac1e90c0705140824i54e1c43ela3ab3d89827c0339@mail.gmail.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: Bahadir Balban Cc: Learning Linux , kernelnewbies@nl.linux.org, linux-newbie@vger.kernel.org, linux-kernel@vger.kernel.org ------=_Part_157389_2355371.1179206274153 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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? Doesn't interrupt steals the CPU slice time allocated to the running process to run? Doesn't it run in current process's context ? What am i missing here? Thanks ~psr 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 ------=_Part_157389_2355371.1179206274153 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

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?
Doesn't interrupt steals the CPU slice time allocated to the running process to run?
Doesn't it run in current process's context ?

What am i missing here?

Thanks
~psr

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 ------=_Part_157389_2355371.1179206274153-- -- 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