[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MSR storing - to Joel and E.Valette
- Date: Thu, 24 Jan 2002 07:56:14 -0600
- From: joel.sherrill at OARcorp.com (Joel Sherrill)
- Subject: 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
> >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
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
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
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
> 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