Why _ThreadProcessSignalsFromIrq() in new exception processing?

Sergei Organov osv at javad.ru
Mon Feb 10 10:39:21 UTC 2003

Joel Sherrill <joel.sherrill at OARcorp.com> writes:
> Sergei Organov wrote:
> > 
> > Joel Sherrill <joel.sherrill at OARcorp.com> writes:
> > > Sergei Organov wrote:
> > > >
> > > > Valette Eric <eric.valette at free.fr> writes:
> > > > > Sergei Organov wrote:
> > > > > > Could somebody please explain what is the purpose of call to
> > > > > > _ThreadProcessSignalsFromIrq() in the new-exception-processing from
> > > > > > the shared_raw_irq_code_entry? Should it be implemented in the old
> > > > > > exception processing for proper RTEMS behavior?
> > > > >
> Nothing looks broken in the c/src/lib/libbsp/powerpc/shared/irq/irq_asm.S to
> me. That code is honoring the internal RTEMS variable
> _ISR_Signals_to_thread_executing and running the post switch extension to
> let signal handlers run before the thread resumes its execution where it was
> interrupted. If the x86 and arm do the same thing, then they are right also.
> [I didn't look at them though.]
> The other ports tend to return to _ISR_Thread_dispatch which calls
> _Thread_Dispatch which does the same thing.
> All looks fine to me.

OK, both ways are not broken so the old exception processing in the PPC BSP is
still OK. This was the primary question I have interested in -- thanks for
clarification. But unfortunately I can't say that all looks fine for me. I'll
try to put remained questions more carefully.

Most of BSPs do basically the same thing. If _ISR_Signals_to_thread_executing
is non-zero, they set it to zero and either call _Thread_Dispatch or return to
_ISR_Thread_dispatch that in turn calls _Thread_Dispatch. This is the
documented way to do things. Fine so far. However, there are 3 BSPs that do
this differently in an undocumented way. Instead of calling _Thread_Dispatch
directly or indirectly, they call their own _ThreadProcessSignalsFromIrq.
Maybe it's OK to do it this way, but the question is: why? I guess there
should be some reason for that. What is the reason?

If there is one, then why the _ThreadProcessSignalsFromIrq is not in the RTEMS
core (like _Thread_Dispatch) and why not all the BSPs call it? Is there an
intention to eventually turn all the BSPs to this new calling sequence?


More information about the users mailing list