On Sun, Oct 18, 2020 at 11:53 PM Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > > On 16/10/2020 19:48, Joel Sherrill wrote: > > > > > > > On Thu, Oct 15, 2020 at 11:40 PM Chris Johns <chr...@rtems.org > > <mailto:chr...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
