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

On 21/10/20 4:46 pm, Sebastian Huber wrote: > On 21/10/2020 04:06, Chris Johns wrote: > >>> Those who are not in constant testing... well they are not tier 1, right? >> Yes but how does that fit in with idea of "being maintained" or "not being >> maintained" and under what terms do we accept chang

Re: set_vector() on SPARC

On 22/10/20 2:10 am, Gedare Bloom wrote: > On Sun, Oct 18, 2020 at 11:53 PM Sebastian Huber > wrote: >> >> On 16/10/2020 19:48, Joel Sherrill wrote: >> >>> On Thu, Oct 15, 2020 at 11:40 PM Chris Johns >> > wrote: >>> >>> On 16/10/20 3:30 pm, Sebastian Huber wrote: >>>

Re: set_vector() on SPARC

On Sun, Oct 18, 2020 at 11:53 PM Sebastian Huber wrote: > > On 16/10/2020 19:48, Joel Sherrill wrote: > > > > > > > On Thu, Oct 15, 2020 at 11:40 PM Chris Johns > > wrote: > > > > On 16/10/20 3:30 pm, Sebastian Huber wrote: > > > On 16/10/2020 03:09, Chris Johns w

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

On 21/10/2020 04:06, Chris Johns wrote: Those who are not in constant testing... well they are not tier 1, right? Yes but how does that fit in with idea of "being maintained" or "not being maintained" and under what terms do we accept changes to BSPs and the interfaces they use? I suppose I am

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

Hi Thomas, Thanks for responding. On 20/10/20 5:52 pm, Thomas Doerfler wrote: > Chris, > > hm, isn't this something related to our tiering of architectures/BSPs? The tiers as they are currently defined do not have the resolution these questions raise. I am not sure tiers could capture the subtl

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

Chris, hm, isn't this something related to our tiering of architectures/BSPs? Those who have a maintainer/test board should detect any fault due to the proposed change rather soon/at the next regular test. Those who are not in constant testing... well they are not tier 1, right? wkr, Thomas. Am

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

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 > > 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:

Re: set_vector() on SPARC

On 16/10/2020 19:48, Joel Sherrill wrote: On Thu, Oct 15, 2020 at 11:40 PM Chris Johns > 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 remov

Re: set_vector() on SPARC

On Thu, Oct 15, 2020 at 11:40 PM Chris Johns 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 in

Re: set_vector() on SPARC

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

Re: set_vector() on SPARC

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. What testing on real har

Re: set_vector() on SPARC

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? What testing on real hardware will there be? Chris _