Why _ThreadProcessSignalsFromIrq() in new exception processing?
eric.valette at free.fr
Mon Feb 10 15:50:22 UTC 2003
> 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
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
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
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
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...
> 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
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
More information about the users