[PATCH] rtems: rtems_interrupt_enable/flash/disable()

[Pavel Pisa]

Hello Sebastian and others,

On Friday 12 of June 2015 17:47:42 Sebastian Huber wrote:
> ----- Gedare Bloom <gedare at gwu.edu> schrieb:
> > I see. It provides the mutual exclusion for (SMP) applications that
> > rely on interrupt_disable/enable locks?
> >
> > I guess we can never get rid of it as long as we allow for users to
> > call isr_disable/enable?
>
> Yes, an alternative is to remove the rtems_interrupt_disable/enable/flash()
> on SMP configurations.  A pure interrupt disable is not really helpful.

this is exactly same debate as has been solved in Linux kernel
lists more years ago. The Linux kernel community resolution was
to forbid control global interrupts disable from drivers
and all kernel code. Only option is to proceed with local
(on singel CPU) disabel operations

  local_irq_save(flags)   
  local_irq_disable()

  local_irq_restore(flags);

The original function names for global irq disable and enable have
been kept on single CPU configurations for some transition period.
Then they have been removed without replacement.

Local IRQ disable is good mostly to build other synchronization
primitives. At the level of drivers and higher level code
they are not of much use, because there is no guarantee that code
manipulating same data is not run on the other CPU.
So at the end allmost all sites solely combine disable of interrupt
together with spinlock

macro to store flags
  spin_lock_irqsave(lock, flags)
function
  spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags)

These lock do not deadlock even when called from interrupts,
because any lock of this kind could be taken when IRQ
is enabled.

As for RTEMS, I would suggest to follow the same road.
That is to define 

  rtems_local_interrupt_disable/enable/flash()

and for compatibility define rtems_interrupt_disable/enable/flash()
to use these on UP targets. Fail the build of applications directly 
manipulating by IRQ state on the SMP targets. There are not much SMP
applications and targets yet runnuning on RTEMS. So the impact is not
so wide for start and as the applications are transformed to use
irqsave spinlocks when the are moved to SMP environment. If the global
IRQ disable is supported then applications do not stop to use it
and it would lead to need keep support of this feature for too long.
Even if you decide that providing global IRQ disable is required
for now it should be defined with deprecated attribute to be extremely
noisy.

In the general, if application/code needs global guarantee that
some interrupt hander routine is not in the action during some
data/state manipulation, it should disable that single interrupt source
and there has to be provided synchronization which spins till given
interrupt service routine is not finished if it is actually running
on other CPU. But real global interrupts disable should not be required
at all. This is indication that code is broken as Sebastian states.

Best wishes,

              Pavel