[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MSR storing - to Joel and E.Valette



Leon Pollak wrote:
> 
> On Thursday 24 January 2002 14:05, you wrote:
> > leonp wrote:
> > > On Thursday 24 January 2002 12:32, you wrote:
> > > But what to do in my case - I want to disable IRQ globally, I don't want
> > > HW events to occur?
> > Why do not use the external hardware controller? You can disable all
> > interrupts at SIU level just by clearing or setting to 0xffffffff in a
> > 32 bits word. For me this is the right way to do. But, from a
> > theoritical design point of view, if you manipulate this kinds of bits
> > with selective values (nor everything on or off) at thread level, then
> > you should make the thread non-preemptible...
> OK, but here it seems to me we have some inconsistency.
> >From one side saving MSR at a context switch we want to reach IRQ state per
> thread.
> >From another side, the current interrupt priority level is set in SIU, but it
> seems to be not saved in context.
> This means, if I have not missed something,  that Joel's goal to preserve the
> interrupt level per thread remains unimplemented.

RTEMS (the executive proper) has in general never considered interrupt
controllers part of the per-thread context switch.  In order to properly
support this, there would have to be general hooks for BSP specific
support
to do this.  I know that many PowerPC VME boards would have a terribly
ugly time of providing a general solution.  

RTEMS takes the simple route and simply masks external interrupts at
the CPU level across all ports.  If you want the external interrupt
controller
state to be managed per-thread, then I suggest you consider adding a
user extension that manages it.  I believe you could use the newlib
reentrancy extension as a model.  I think the behavior is similar --
at task create, allocate and initialize a PIC context strucuture. At
switch, save old and restore new.  At delete, free the memory.  You
might
want to address the semtantics of restart.  I think we usually do this
by having task begin actually do the initialization to a default state.

> --
> Dr.Leon M.Pollak
> Director
> PLR Information Systems Ltd.
> leonp at plris.com

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985