From: "Dong Feng" <middle.fengdong@gmail.com>
To: Bahadir Balban <bahadir.balban@gmail.com>
Cc: Learning Linux <learninglinux4@gmail.com>,
pradeep singh <2500.pradeep@gmail.com>,
kernelnewbies@nl.linux.org, linux-newbie@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: Why can't we sleep in an ISR?
Date: Mon, 14 May 2007 23:56:15 +0800 [thread overview]
Message-ID: <a2ebde260705140856m3917d761xe1067c76fa000b18@mail.gmail.com> (raw)
In-Reply-To: <7ac1e90c0705140824i54e1c43ela3ab3d89827c0339@mail.gmail.com>
I agree that the reason an interrupt can not sleep is because an
interrupt is not associated with any context. But I do not agree that
it is specifically because the scheduler can not *resume* the context.
In early version, the ISR always borrow the stack of the currently
running process, so if the kernel design had allowed ISR sleep, it
would automatically be able to implement the context switch naturally.
But ISR sleep has been forbidden from the very beginning.
The reason why kernel design does not allow ISR sleep is because a
process should not be forced to wait for a event that irrelative to
itself. When an exception handler sleep, the event it sleeps on is
always in some sense related to the process incurring that exception.
But if an ISR was allowed to sleep, the event it sleeps on would have
nothing to do with the process being interrupted.
So my understanding is, the forbidden of ISR sleep is not because of
the difficulty to resume context, but because a process should not
wait for irrelative event.
2007/5/14, Bahadir Balban <bahadir.balban@gmail.com>:
> 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. 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
>
> --
> 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
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
next prev parent reply other threads:[~2007-05-14 15:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-14 6:37 Why can't we sleep in an ISR? Learning Linux
2007-05-14 7:10 ` pradeep singh
2007-05-14 7:16 ` Learning Linux
2007-05-14 15:24 ` Bahadir Balban
2007-05-14 15:56 ` Dong Feng [this message]
2007-05-15 5:17 ` pradeep singh
2007-05-15 6:45 ` Dong Feng
2007-05-15 7:10 ` pradeep singh
2007-05-15 7:28 ` Dong Feng
2007-05-15 8:12 ` pradeep singh
2007-05-15 8:40 ` Learning Linux
2007-05-15 8:58 ` Dong Feng
2007-05-15 16:57 ` Phillip Susi
2007-05-15 22:49 ` Dong Feng
2007-05-16 15:20 ` Phillip Susi
2007-05-16 23:17 ` Dong Feng
2007-05-17 16:07 ` Phillip Susi
2007-05-17 23:50 ` Dong Feng
2007-05-14 12:25 ` Helge Hafting
2007-05-14 12:52 ` pradeep singh
2007-05-14 13:36 ` Dong Feng
-- strict thread matches above, loose matches on Subject: below --
2007-05-14 15:22 linux
2007-05-14 15:55 ` Rik van Riel
2007-05-15 9:34 rohit hooda
2007-05-15 9:46 ` pradeep singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a2ebde260705140856m3917d761xe1067c76fa000b18@mail.gmail.com \
--to=middle.fengdong@gmail.com \
--cc=2500.pradeep@gmail.com \
--cc=bahadir.balban@gmail.com \
--cc=kernelnewbies@nl.linux.org \
--cc=learninglinux4@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-newbie@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox