set_vector() on SPARC
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.
> devel mailing list
> devel at rtems.org
More information about the devel