BSP maintenance (was Re: set_vector() on SPARC)

[Chris Johns]

On 19/10/20 4:51 pm, Sebastian Huber 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.

BSP maintenance is hard and in this context the term "maintained" is subjective.
I feel there exists a grey area that is not defined in a way that makes it clear.

The following questions are an attempt to scope the problem and not a specific
set of questions directly related to the set_vector changes. As a result I have
changed the subject. I will leave you and Joel to debate that subject.

If these architectures are not being maintained as you suggest where do we
document this and how do we inform the users?

If you did update the architectures to remove set_vector are they now maintained?

Is updating the code without being able to test the changes maintaining an
architecture or BSP or do we require some level of testing?

Other factors effect how far you go such as the size of the change. Is being
able to change an architecture or BSP better than not being able to post a
change because changing all architectures or BSPs is too large a task?

>>     >> 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 and this is an important point to discuss. Is a change that is not tested
better than not having the change made? This becomes hard because it leaves a
liability in the code if it is not changed. If a BSP breaks and you open it up
to fix and you find it is behind the "current" interfaces do you fix the bug or
do you update the interface(s) and fix the bug? I have this situation with the
mvme2307 BSP at the moment.

I do not have answers for these questions but I feel we need to discuss the
topic and attempt to frame a context.

Chris