What happens next (Was ISR Argument Proposal Request)

[Joel Sherrill]

Till emailed me off-line asking for the next step but I
didn't get to replying yesterday. Sorry.

Valette Eric wrote:
> 
> 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.

I still lean to yes and would like to see it taken further so at least
the API for installing an interrupt is the same on all ports.

> >  + 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...

Agreed but the source code will only see it as an
rtems_interrupt_argument.

> 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),

On the PPC and MIPS, this is true but on CPUs like the m68k you have
256 vectors.  So the natural solution of declaring an array of 
structures -- one for each vector -- is the problem.  Chris Johns
suggested allocating the structures in chunks and having the 
table that is number of vectors big be a pointer to an "ISR handler
structure".  That is probably the right thing to do to minimize 
memory and should be able to be some generic, shared support code.

If the pointer is NULL, then invoke a default handler.
 
> 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...

My concern was primarily the mips pointer and this is not an issue
as the stack frame pointer is passed to a CPU/BSP specific support 
routine which is actually the "vectoring code".  So this would impact
the code found in libcpu/mips/*/vectorisrs and probably not
score/cpu/mips.

> 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

I think the complexity here will be mostly on the CPU families with
large numbers of vectors where one might want to keep the memory 
size down.  

> 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.

I am concerned more with a unified API for hardware interrupt handlers.
If a port has distinct way of dealing with exceptions, then so be it.
The handlers are usually not portable anyway.  

>  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. 

ANd I won't take this bait. :) 

> Anyway defining the vector number to connect the interrupt in a
> portable way would be quite funny...

Why? vector number is just an unsigned32.  it's meaning is very CPU
specific but the fact that it is an arbitrary 32-bit number is not.

> 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.

I still believe that whether the code is implemented in the score/cpu,
libcpu, or BSP level that the API should be as unified as possible --
especially for core services like ISR installation.  How it is 
implemented is different from the API implemented.

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

The mips port impact will be trivial.  Greg and I were looking at the
assembly code when in fact, the vectoring code is actually in C.  The
mips usually has < 32 interrupts so memory overhead isn't even an issue.

The sparc and m68k have 256 vectors. I agree that on most systems, there
are actually only a handful (<32) interrupt sources.  So there needs to
be a way to minimize the memory impact on those systems.  I do not
believe it is a big deal to implement on either system -- just a
resource
concern.  And I believe that the same solution could be employed on both
ports.

A quick grep points out that a memory saving technique will be required
on the sparc, sh, m68k, and i960 ports.

Post release branch, I am willing to deprecate the a29k and hppa 1.1
ports since it is likely no one is using them and there is no point
investing effort in them.  The mips64orion port should be OK to
drop once the RTEMS release branch is cut and gcc 3.3 is out.  Since 
gcc 3.3 has proper multilib support for mips1 and mips3 at the same
time.

> 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?

Jay Monkman would be the natural person at this point if he is willing.
Fabrio (sp?) might also be willing since he can test on his simulator.
I can probably do it but am at a slightly greater risk.

> 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.

This is what I was going to ask him to do.  Please try to meet these 
requirements:

   + existing rtems_interrupt_catch interface works on all ports
   + rtems_interrupt_catch_with_argument (name?) works on all ports.
   + ISR handlers have the same function signature on all ports.
   + Null in the table means default handler .. name and maybe 
     signature of that routine should be the same on all ports.

The implementations will require the support of cuhnk memory allocation 
for handler structure entries like Chris described.  Chris... would you 
be willing to implement something like that?

>         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,

I am not great with CVS branches but would be willing to make a
development
branch specifically for this work.

>         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...

I think making a development branch would be the best way to approach
this.
When all are ready, we merge the branch.

>         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...

Agreed.  

> 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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985