set_vector() on SPARC

[Chris Johns]

On 22/10/20 2:10 am, Gedare Bloom wrote:
> 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

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