[GSOC] Query regarding wrapping PIC support to Simple Vectored Architectures

[Gedare Bloom]

I don't have answers to your two questions specifically. However, I
did some unification work related to set vector over a year ago that
never got committed. See
http://git.rtems.org/gedare/rtems.git/log/?h=setvec
2012-04-16bsps: rename set_vector to bsp_set_vectorGedare Bloom
2012-04-16bsps: add macros for set_vector RAW and RTEMS typesGedare Bloom
2012-04-16bsps: create shared setvec.h for set_vector prototypesGedare Bloom
2012-04-16lm32: use shared setvec.cGedare Bloom
2012-04-16m68k: use shared setvec.cGedare Bloom
2012-04-16lm32: replace lm32_isr with rtems_isrGedare Bloom
2012-04-16m68k: replace m68k_isr with rtems_isrGedare Bloom

I think that you could study my effort (maybe even replicate/use those
patches, although they might not apply to current HEAD) as a first
step to unifying the set vector approach.

On Sun, Aug 25, 2013 at 1:09 PM, Vipul Nayyar <nayyar_vipul at yahoo.com> wrote:
> Hello,
>
> As per my proposal, one of the task is to generalize the PIC interrupt
> support in sparc to support any other simple vectored architecture. I think
> I get the hang of how SPARC wraps the shared PIC IRQ code on top of the
> Simple IRQ Model. I had some questions & thoughts, that need your guidance.
>
> 1)  I think there is no need of bsp specific bsp_dispatch_irq() in sparc &
> can be replaced with the inline bsp_interrupt_handler_dispatch(), which is
> written in irq-generic.h
>
> 2) From what I saw, the set_vector() is mainly used to install a vector &
> rtems_interrupt_catch() once in the interrupt initialization function. For
> ex: I'll be working on m68k bsp now. So from what I saw, most of the files
> use rtems_interrupt_catch() to install an ISR. Following the trend in sparc,
> I should change rtems_interrupt_catch() in all files to set_vector() right ?
>
> Any other crucial points that I should keep in mind ?
>
> Regards
> Vipul Nayyar
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>