Why _ThreadProcessSignalsFromIrq() in new exception processing?

[Valette Eric]

> This is what I've asked about. Your words "almost mandatory" imply that the
> BSPs that don't do that are "almost broken", isn't it? And Joel says they are
> fine.

I did not want to imply the old code was wrong. What I wanted to say is 
that *not* calling ThreadProcessSignalsFromIrq in new exception code is 
broken because as Joel and myself have pointed out, it is required for 
posix signal handling. If you really do not use signal handling at all 
you can simpyfy the code...

> Current code doesn't use CTX argument and I mean that part of code. It is
> processor/bsp independent (in fact it is a copy of a few last lines of
> _Thread_Dispatch) and so should better reside in the kernel, isn't it? It
> could be then called both from _Thread_Dispatch and from
> _ThreadProcessSignalsFromIrq.

First, I could have called _Thread_Dispatch as most IRQ do. BUT, in that 
particular path (scheduling not needed, post schedule code needs to be 
runned), most of the _Thread_Dispatch code is not used and only the code 
duplicated in few last lines of _Thread_Dispatch is. So it is a kind of 
optimization.

Besides, and I talked about this with Joel long time ago, if one day a 
BSP implements User/Supervisor mode or real software exception, the 
right place to call the signaling mechanism is just before returning to 
application code and in no way in the dispatching code (that anyway use 
the supervisor address space and has no way to find back the thread 
registers when entering the IRQ).

To finish the justification about pushing a context, try to think about 
a way with the old exception code to implement the following : hitting 
the pause button on the keyboard enters a monitor that display the 
registers of the thread that was running when key was pressed and wait 
for keyboard input... Any kernel debugger just need that.

> Resistance is just helpful. 

I would say constructive criticsm and proposal for enhancement is. 
Resistance is futile :-)

> There should be a reason to switch to something
> new when old works, not a reason to don't switch, and still I didn't see
> anything in the new code that is significant enough *for me* to justify the
> switch.

For you maybe. For many others wanted to use either remote debugging, 
exception handling it is. Besides, old code lead to other duplication of 
code *inside each BSP* to effectively enable interrupt at PIC level 
(understand SIU+CPM or OpenPic+ 8259) at IRQ connexion and also to 
acknowledge, mask current IRQ for each ISR handler.

> Also I prefer to stay with the majority whenever possible, and the new
> exception processing is not yet the majority, I think.

Most *current, active* PPC BSP use the new exception scheme I think 
(most motorola board, many mbx8XX, ... All Ix86 BSP use it. It is 
unfortunate that the 8260 code do not use it.

 > I just
> wanted to let you (and others) know there possibly is a problem.

There is a problem *when you use non standard compilation switches*. I 
bet if we play with other gcc switches we may find others... Beside and 
you agreed, it could be curred by a simple sed command...

> An
> interesting thing though is that there are currently 4(!) almost identical
> copies of the 'irq_asm.S' in the PPC BSPs that looks to me as rather bad
> style.

I think having diffrent ISR asm code for 8XX, and 6XX is quite normal as 
8XX have integrated interrupt controller (SIU + CPM, ...) and 6XX 
usually have an OpenPIC + 8259. Having the same code duplicated for one 
familly is just a matter of someone making autoconf/automake makefile 
part clever as I have done on ix86 related BSP... Do you candidate?

NB : I maintain IRQ handling should stay BSP dependend has more and more 
processor have external PIC to multiplex irq on top of a single IRQ 
line. If you change the PIC, It can happen that code is totally 
different. That said, avoiding code duplication is indeed a good goal.


> Please don't get me wrong. Criticism is not my goal. I just try to understand
> particular differences between two implementations, reasons behind them, and
> consequences of switching from old to new exception processing.

I think wording old/new exception processing is misleading. Among other 
things that the new IRQ handling schemes brings are :
	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, ...
	2) It manage all generic part of the irq handling code (not just 
calling the handler) and release you of the need to acknowledge the IRQ, 
masks other IRQ at PIC level, reenable IRQ once handler has been called. 
You just need to handle the *real* device level,
	3) Separate IRQ handling from exception handling,

> Yet I didn't say even single word about exception handling. If you are
> interested in my opinion though, I agree with you that it's a good idea to
> keep exceptions API separate from ISRs API (they can share [parts of]
> implementation though).

They do share already on PPC as low level IRQ vector is connected using 
the raw execption handling connexion API...



-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette at free.fr