Hello Sebastian and others, On Friday 12 of June 2015 17:47:42 Sebastian Huber wrote: > ----- Gedare Bloom <ged...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel