set_vector() on SPARC

Gedare Bloom gedare at rtems.org
Wed Oct 21 15:10:34 UTC 2020


On Sun, Oct 18, 2020 at 11:53 PM Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>
> On 16/10/2020 19:48, Joel Sherrill wrote:
>
> >
> >
> > On Thu, Oct 15, 2020 at 11:40 PM Chris Johns <chrisj at rtems.org
> > <mailto:chrisj at rtems.org>> wrote:
> >
> >     On 16/10/20 3:30 pm, Sebastian Huber wrote:
> >     > On 16/10/2020 03:09, Chris Johns wrote:
> >     >> On 16/10/20 4:57 am, Sebastian Huber wrote:
> >     >>> I suggest to remove this function and replace it with
> >     rtems_interrupt_catch()
> >     >>> and add the interrupt enable to rtems_interrupt_catch().
> >     >> Which BSPs will this effect?
> >     >
> >     > All SPARC BSPs.
> >
> >     OK.
> >
> >
> > Unless you make that all BSPs which have set_vector, I am not in favor
> > of this.
> >
> > set_vector() was intended many many years ago as a central place for a
> > BSP
> > to touch an interrupt mask register if it had one. This was sometimes
> > present
> > on architectures which we now call simple vectored. This was universally
> > present across all simple vectored architectures.
> >
> > If you want to eliminate it, do so. Don't leave it partially present.
> My intention was to change this only on SPARC. The other architectures
> that use set_vector() are not really maintained.
> >
> >
> >     >> What testing on real hardware will there be?
> >     >
> >     > I will test on GR712RC and GR740. I hope Gaisler tests the RTEMS
> >     master from
> >     > time to time on their hardware.
> >
> >     Yes. Testing as we are working on changes is much more helpful
> >     than finding out
> >     long after the focus has shifted.
> >
> >
> > +1
> Testing this change on everything except SPARC would be difficult.

Yes. I actually refactored this set_vector stuff (9 years ago!) and
didn't push it because testing was not possible. At that time I was
just looking at how to make set_vector uniform across BSPs.
https://git.rtems.org/gedare/rtems.git/log/?h=setvec

> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


More information about the devel mailing list