Why _ThreadProcessSignalsFromIrq() in new exception processing?

[Sergei Organov]

Eric Valette <eric.valette at free.fr> writes:

> Sergei Organov wrote:
> 
> > Non standard? Hmm... I'd call PPC EABI the natural standard for embedded
> > applications... If it's not standard for PPC port of RTEMS, it's failure
> > of the port, I believe. Besides, old exception processing code did handle
> > it fine.
> 
> Just wanted to say that code in rtems with the actual compilation flags was
> working. You triggered a bug by using compilation flags different than the
> one in the BSP...

Yes, in these sense the flags that would trigger the bug are non-standard.

> 
> > I believe the problem is not in autoconf/automake files. The problem is
> > that the code in shared/irq_asm.S is not parametrized by CPU features as
> > the old exception code was. Because of this BSP writers seem to take
> > simple way of making a copy of the file and making required small changes
> > in the copy.
> 
> I disagree : having nested ifdefs make code hard to understand and maintains.
> Ifdefs are just different copy of code located in the same files...

Even [nested] ifdefs are better than duplication of 99% of code in every BSP.

Anyway, you don't need nested ifdefs or even non-nested ifdefs to handle this.
This could be handled by BSP-provided macros.

> 
> >>	1) provide the On/Off/IsON handler that simplify the BSP code because
> >>you have not to call the connect part and after that duplicate code to
> >>enable the interrupt on the device, manage PIC, ...
> > Sorry, I consider this to be more a drawback than an advantage. The extra
> 
> > level of abstraction in disabling/enabling/query interrupt status doesn't
> > come without cost. For example, in my case it would replace about 3 asm
> > instructions required to read/modify/store a hardware register with
> > indirect function call through a pointer in the interrupt structure that
> > even can't be inlined due to its indirect nature :-(
> 
> But we are speaking of code executed only at handler connexion!!!

Aren't On/Off/isOn called while interrupt processing as well? If not, then
their usefulness is even less than I thought before.

> Many preople prefer to ahev no asm to write at all for handling irq...

I don't suggest to force them to write asm. It's BSP that should provide the
required (possibly inline) routine(s).

> > Also, connection of interrupt handler and enabling the interrupt are rather
> > different activities, so I don't see where code is duplicated in the first
> > place.
> 
> Each time you connect a vector, you need to code the actual manipulation of
> CPM/SIU bitmask to effectivelly enable the interrupt.

Hmm... It seems you know better than me what I need :-)

> What is the use of connecting a vector without effectively enabling the irq?

It will be eventually enabled, but later. For example, I don't need Tx
interrupts until I have something to transmit. So I prefer to make the slow
part of job (interrupt attachment) to be done in advance, but the fast part of
job (IRQ enabling/disabling) only when required.

> 
> > Sorry, but this also seems to be a wrong approach for me. I doubt there
> > exists generic algorithm that handles all the cases the way I need it.
> > Just for example, what if I don't need to re-enable the IRQ once handler
> > has been called as I have ISR handler that only posts a semaphore and then
> > manage the hardware from inside a thread waiting on this semaphore. In
> > this case re-enabling IRQ will result in forever loop as the device wasn't
> > yet managed and thus didn't yet remove its interrupt request.
> 
> Use raw irq API and make whatever you want. Some interrupt do not even need
> to call the OS if processor stay masked...

But then all the "advantages" of the new exception handling are gone. Only
dead code and data are left :-(

> 
> > Also very frequently I don't need to enable an IRQ automagically after
> > I've installed ISR handler to it. All this automatic handling just brings
> > more troubles, IMHO.
> 
> Supply a nop in intrOn... What abig deal!!!

Why should I pay for the code that I never use?

Do you really believe that calling your variant of attachment (along with
filling in the irq_info structure and passing it to the routine) is in any way
better than calling a simple attachment routine and then IRQ enabling routine
(if required)?! Any given function should better do a single job -- this is
one of the keys to flexibility and usability.

Overall, this discussion seems to be too abstract to me. You think you are
right, I think I'm right. Care to give an example code that certainly benefits
from the approach you've taken in the new exception processing when compared
to other possible approaches?

-- 
Sergei.