public inbox for linux-newbie@vger.kernel.org
 help / color / mirror / Atom feed
From: "Dong Feng" <middle.fengdong@gmail.com>
To: pradeep singh <2500.pradeep@gmail.com>
Cc: Bahadir Balban <bahadir.balban@gmail.com>,
	Learning Linux <learninglinux4@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: Tue, 15 May 2007 15:28:06 +0800	[thread overview]
Message-ID: <a2ebde260705150028j16cc12a2ya6d5906c97ce193b@mail.gmail.com> (raw)
In-Reply-To: <366312910705150010p623f9732mc498f457245d23a1@mail.gmail.com>

> >
> > I don't think so but I am not sure.
>
> Aliter, i think so.How can an interrupt's execution time go
> unaccounted then?
> I guess it does not, only the current processes running
> time is accounted for.
> Thoughts?
>

The interrupt handler's execution time will definitely defer the
execution of the process, but I think it does not steal the process's
time slice (the time_slice field not subtracted).

> > > Doesn't it run in current process's context ?
> > >
> >
> > No. I think the concept of process context is a higher-level logical
> > concept. Though the interrupt share stack with the interrupted
> > process, in my opinion it logically does not share the context with
> > the process.
>
> Yes, you are right as i can infer. thats why ISRs
> are special kernel control paths.
> But the poster asked, why can't we make ISRs to
> share context with the interrupted process
> if
> it not holding any locks? This is rather a desing issues
> IMO rather than imlementation, isnt it?
>
> I guess even if it is possible, it would over complicate the handler code.
> Better trying to keep it simple i guess. Please CMIIW

My understanding is, the ISR is in different context from the process
because of the definition of term *context*. In my opinion, to say two
code pieces running in the same context means that two pieces of code
has some logical relationship to meet a common objective. That's why I
said *context* is a higher-level logical concept. It's not a concept
defined in the level of hardware or code implementation, but instead
in the level of logical. I think, by its definition, it makes no sense
to say an ISR share context with the process interrupted by it because
an ISR just randomly interrupts a process, with no logical
relationship.
-
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

  reply	other threads:[~2007-05-15  7:28 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
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 [this message]
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=a2ebde260705150028j16cc12a2ya6d5906c97ce193b@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