What happens next (Was ISR Argument Proposal Request)

[Valette Eric]

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

No problem.

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

Joel, I understand this but on the other hand, look at the code as it is 
today on BSP not using the new API. You connect the irq using a shared, 
generic API but the BSP code has to manually enable the irq at device 
level and also disable it if needed. This hardware 
enabling/disabling/isOn function cannot be guessed by external/generic 
code so anyway the code for effectively connecting the IRQ is BSP 
dependent (actual value of the vector to connect is also). Or we agree 
to pass an additionnal structure to contains irqOn/irqOff/irqIsOn.

Look at the various svIntrAttach at :

<http://www.jaluna.com/doc/c5/html/ManPages/s.html>

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

Fine for me.

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

I think you are somehow confusing the raw vector table and the rtems 
managed irq higher level irq table. If hardware require a 255 array 
table, fine. But I think most actual entry are the same for irq on one 
side and exception if managed on the other side.

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

I do not think so as the argument table can be stored away from the VBR. 
Usually computing the irq index is one instruction so...


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

same for the code that enables the irq on the device. Today all OS I 
have seen excapt ChorusOS do not provide the function to really enable 
the irq and therefeore, even with an apparently unified API, it is not 
true. NB kernel debugger usually need to disable IRQ and sometimes they 
cannot do just a maskall at processor level...

BTW as far as I know ChorusOS and VxWorks have processor specifc API 
(close to each other but not totally equivalent).


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

I mean the actual value of the vector not its type. I do not even speak 
about at which priority I want the irq to occur (e.g the level on 68k) ...

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

I agree on the goal, but not really on the details for concrete reasons. 
What part of the generic code do actually connect an irq? I think we 
would endup saying that thei part of the code should be replaced to 
implement a call from generic to BSP to get handle to perform some 
initialization task (e.g connect the ticker, get character basic IO like 
putchar,...).



> 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

No the new one :-) What about this one 
<http://www.jaluna.com/doc/c5/html/ManPages/hman9dki/svIntrAttach_powerpc.9dki.html>

BW you also have a page for exception handler in the s section.



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