What happens next (Was ISR Argument Proposal Request)

[Valette Eric]

Joel Sherrill wrote:
> Till,
> 
> I think that we are all as much in agreement over this as we
> will ever be.  Let's see if I can summarize and request that
> you write up the API changes with a list of "key" area to 
> change.
> 
> Some issues that must be resolved:
> 
>  + should rtems_interrupt_catch be backward compatable and
>    this functionality have a new entry point?  I lean to yes.
>  + should this feature be optional and conditionally compiled?
>  
> The development plan needs to have volunteers for each of 
> the following:
> 
>   + generic change from table of handlers to table of 
>     handlers/arguments
>   + each port's irq handling
>   + API changes to original interrupt API, ppc, x86, and ARM
>   + documentation changes
>   + any work break down I am missing?
> 
>   NOTE: When you change a port, I would consider that to include
>   getting all the BSPs modified.  Everything should still build.
>   I regularly build all BSPs so this is somethign I can provide
>   feedback on.
> 
> We can't start this until we are confident all
> the ports will get updated.

As the discussion has ended without conclusion, I think it is time to 
summarize some of the points that have been mentionned by various people 
and propose a path to try to go further.

1) There seems to be an agreement for a pointer type argument (void* 
except for purist like ralf). I agree typed argument is better but 
anyway keep in mind the first instruction will probably cast the 
argument it to the real per driver private data structure...

2) Joel has been concerned about the possible 1K data size but as I 
pointed out, this is false as generally no more than 15 interrupts 
sources are avialiable (false on some SOC type device like 8XX but stay 
resonnable and usually inferior to 32),

3) Then an additionnal frame context pointer as second argument came 
into the picture. I explained that this kind of suggestion comes from 
the fact that in rtems irq and exception handling use the same API on 
many cpu types. I mentionned various reasons why this is a fundamental 
error even if real implementation of the two function is close :
	a) Interrupt never need to have a full cpu context pushed before 
calling the handler, exception handler do,
	b) The private data argument is useless for exception handler,
	c) On some cpu, implementation is totally different (e.g ix86),
	d) handling priorities among interrupt is important and can be achived 
on some hardware using the PIC (ix86 is fully functionnal. It can be 
done on easilly on PPC OpenPic, and is done via a static table on  PPC 
8xx). Exception priorities are usually fixed by design...

4) As joel, Till and myself have pointed out many times, in fact, in 
todays rtems code, there are two kind of irq handling API :
	a) The original one for most CPU (rtems_interrupt_catch),
	b) A more sophisticated one I have designed and implemented on ix86, 
PPC [67]xxx, PPC 8xxx, and partially on ARM. This more sophisticated 
API, is implemented togheter with an exception handling API that is 
mainly used for debugging today but would be necessary on some port for 
recoverable exception handling, reboot on failure, ...
	
Modifying the b) type API for adding a void* (sorry ralph) is almost 
trivial, in consist mainly to add a second field to the handler table to 
record the argument passed when calling the irq connect routine.[67] xxx 
and 8xx code modification is vastly similar allthough detail on how to 
really hanlde the irq differ. On ix86, unfortunately for performance 
reasons, the handler is called directly in asm which complicates a 
little bit the task but anyway it is not such a big deal

5) IRQ handling should be BSP dependend. Trying to unify the API among 
ports will cost more than it will bring. I have nothing against trying 
define a common wrapper for all port (as rtems_interrupt_catch is today) 
  but as exception and irq are mixed on some port, it will be hard. It 
is mainly designed in the goal to have libchip availiable on most port. 
I will not comment again about libchip just say I would have designed it 
differently while fully in agreement with its original goal : code 
reuse. Anyway defining the vector number to connect the interrupt in a 
portable way would be quite funny...

6) If IRQ handling was fully BSP implementation dependend (it is close 
but not fully like that), modifying CPU specific port would not hurt any 
other ports and I think it is worth looking into that direction before 
making the actual changes. Note that when I say BSP dependend, I do not 
mean most code should not be shared like on ix86.

7) Indeed sparc and mips  and 68k port maintainer have expressed their 
concern about impact of the modfication on their BSP.

8) Till proposed to do the PCC port (I'm not sure if he meant [67]xx and 
8xx. I think the two are so close that it should be done). If really 
necessary I can make the Ix86 changes provided someone test the code for 
me... Chris John and EricN have proposed help for 68K and coldfire. I do 
not know who can make the Arm?

So first question, I would like to ask is if the 8 points of my above 
summary are accurate, understandable, accpetable for most people. Please 
comment.

Now, I would like to propose a path to progress :

	1) Till makes a proposal of the new irq API for PCC by proposing a 
revised PPC irq.h file. This file is reviewed by people in charge do do 
the port to other architecture + joel and myself.
	2) Once we agree on the new irq.h, Till implement effectively the code 
for PPC. Changes are reviewed by volunteers (I'm candidate). He should 
point out the damage done on other ports without trying to fix them at 
first. This way we will have an idea of the impact of the modification 
on other ports and see if there is a way to minimize them,
	3) Once work is done for PPC, other volunter make the change to the BSP 
already using the new irq handling API (ix86, Arm). At this point I hope 
Joel can feel enough confident to commit the chnages...
	4) Other CPU/BSP use the code from one or other already modified CPU to 
implement the high level irq handling. I think 68K port would help a lot 
other ports...
	
Again suggestion critics are welcome.

-- 
    __
   /  `                   	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