public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Xavier Wang" <xavierwang@ms19.url.com.tw>
To: <ecos-discuss@sources.redhat.com>
Subject: Re: [ECOS] nested interrupts
Date: Thu, 18 Jan 2001 21:52:00 -0000	[thread overview]
Message-ID: <00e101c081d2$c124bee0$6f2314ac@realtek.com.tw> (raw)
In-Reply-To: <wwgsnmh2dih.fsf@balti.cambridge.redhat.com>

> > 
> > One more question. By looking into the source code, I still can't
> > figure out that why DSRs can call most kernel functions but
> > ISRs can't. Is it the stack problem or scheduler locking problem
> > or something else?
> 
> The kernel does not block interrupts during critical sections, so an
> ISR can occur at any point, even while the scheduler is manipulating
> the run queues. If the ISR then tries to manipulate the same data
> structures, by calling a kernel function, then they will be
> corrupted. Hence the use of DSRs to defer these calls until the data
> structures are in a consistent state.
> 
> 
> -- 
> Nick Garnett, eCos Kernel Architect
> Red Hat, Cambridge, UK

Thanks for your explanation. But I still got confused.
As described by Gary Thomas in
http://sources.redhat.com/ecos/docs-latest/porting/hal-interrupts.html

> The way it is supposed to work is like this (pseudo-code to abstract
> machine details):
>
> VSR:
>   mask interrupts (if necessary)
>   save interrupt context on thread stack 
>   lock scheduler
>   switch to interrupt stack (if defined)
>   call ISR
>   switch back to thread stack
>   call interrupt_end
>   restore interrupt context from thread stack
>   exit VSR
> 
> Note: interrupt_end called with interrupts disabled, scheduler locked
> 
> interrupt_end:
>   possibly schedule a DSR, based on paramters from VSR
>   drop scheduler lock  
>   if scheduling enabled, run pending DSRs (actually just part of scheduling)
>   note: interrupts are still disabled when entered from VSR
> 
> hal_interrupt_stack_call_pending_DSRs:
>   [disable interrupts (may be moot)]
>   switch to interrupt stack
>   enable interrupts
>   run DSRs
>   disable interrupts
>   switch back to thread stack
>   restore interrupts

Which step above does indeed make the kernel state safe to be called by DSRs?

For example, an interrupt occurred while a thread is running in scheduler's critical
section. It's not safe to manipulate scheduler's data in ISR obviously, but it seems
also not safe to access scheduler's data in DSR since the interrupted thread still
doesn't finish its job to make the data consistent. Am I wrong here?

Thanks.


  reply	other threads:[~2001-01-18 21:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-17 23:51 Xavier Wang
2001-01-18  1:03 ` Jesper Skov
2001-01-18  4:15   ` Xavier Wang
2001-01-18  5:00     ` Nick Garnett
2001-01-18  4:59   ` Xavier Wang
2001-01-18  5:46     ` Nick Garnett
2001-01-18 21:52       ` Xavier Wang [this message]
2001-01-18 22:35         ` Jonathan Larmour
2001-01-18  8:26   ` Sergei Slobodov
2001-01-18 20:56     ` Xavier Wang
2001-01-18 22:37       ` Jonathan Larmour
  -- strict thread matches above, loose matches on Subject: below --
2000-09-11  0:03 [ECOS] Nested Interrupts Sandeep Rikhi
2000-09-11  7:53 ` Jonathan Larmour

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='00e101c081d2$c124bee0$6f2314ac@realtek.com.tw' \
    --to=xavierwang@ms19.url.com.tw \
    --cc=ecos-discuss@sources.redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).