What happens next (Was ISR Argument Proposal Request)
eric.valette at free.fr
Thu Feb 6 10:37:40 UTC 2003
Joel Sherrill wrote:
> 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
> 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
> + 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 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. 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 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
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
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
More information about the users