On 22/10/20 2:10 am, Gedare Bloom wrote: > On Sun, Oct 18, 2020 at 11:53 PM Sebastian Huber > <[email protected]> wrote: >> >> On 16/10/2020 19:48, Joel Sherrill wrote: >> >>> On Thu, Oct 15, 2020 at 11:40 PM Chris Johns <[email protected] >>> <mailto:[email protected]>> 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
This highlights a point I would like to get some resolution on if it is possible. It seems a shame to have this change sit dormant for 9 years because it was not perfect on all BSPs and now we have the possibility of the work being potentially done twice. Chris _______________________________________________ devel mailing list [email protected] http://lists.rtems.org/mailman/listinfo/devel
