[PATCH 3/4] capture: Remove nested rtems_interrupt_lock_acquire calls.

[Chris Johns]

On 10/07/2014 11:44 pm, Jennifer Averett wrote:
> Use of the cenable command was resulting in a lock in
> rtems_interrupt_lock_acquire due to nesting.

I am rejecting this change. RTEMS as an RTOS should provide support to 
handle this case in a consistent manner in SMP and non-SMP builds of the 
code.

The change highlights an issue in RTEMS's locking support. This code 
works on a non-SMP build because the rtems_interrupt_lock_acquire nests 
and this is the functionality of the call it replaces. It is dangerous 
to promote rtems_interrupt_lock_acquire and rtems_interrupt_lock_release 
as replacements for old interrupt disable and enable calls if they are 
not functionally the same as the code they replace and functionally the 
same on SMP and non-SMP builds.

I understand the current implementation of the rtems_interrupt_lock_* 
code is optimised for performance and adding nesting checks adds 
overhead however I feel we should considering providing support with 
no-nesting versions for code that can support this. The pattern in the 
capture engine this change addresses is a common one and forcing users 
to remember this issue and then rewrite exist code to manage it is not 
being a helpful RTOS.

Chris