>> >> >> >> >> #ifndef DEFINE_SEMAPHORE >> >> >> /* Legacy DECLARE_MUTEX vanished in 2.6.37 */ >> >> >> #define DEFINE_BINARY_SEMAPHORE(sem) DECLARE_MUTEX(sem) >> >> >> -#elif defined(CONFIG_PREEMPT_RT) >> >> >> -#define DEFINE_BINARY_SEMAPHORE(sem) DEFINE_SEMAPHORE(sem, 1) >> >> >> +#elif defined(CONFIG_PREEMPT_RT_FULL) >> >> >> +#define DEFINE_BINARY_SEMAPHORE(sem) DEFINE_SEMAPHORE(sem) >> >> >> #else >> >> >> #define DEFINE_BINARY_SEMAPHORE(sem) DEFINE_SEMAPHORE(sem) >> >> >> #endif >> >> >> >> > Why that change? I mean in 2.6.37, the define was CONFIG_PREEMPT_RT >> >> > anwyay. >> >> >> >> If DEFINE_SEMAPHORE is not defined we are below 2.6.37. So for 2.6.37 and >> >> above CONFIG_PREEMPT_RT was checked. >> >> > Well, are not we in the "elif" case of the #ifndef DEFINE_SEMAPHORE, >> > so DEFINE_SEMAPHORE is defined, or am I missing something ? >> >> Let me explain that more in detail: >> >> DEFINE_SEMAPHORE is defined for linux >= 2.6.37 >> >> So for linux 2.6.37 we are in >> >> #elif defined(CONFIG_PREEMPT_RT) >> >> Also in linux 3.0.0 we are in that elif. Since in 3.0.0 and above >> CONFIG_PREEMPT_RT >> was changed to CONFIG_PREEMPT_RT_FULL, so we have to use the latter one >> instead.
> Ok, but please the two ifdefs then, one for PREEMPT_RT and the other > for PREEMT_RT_FULL. This will avoid breaking is someone decides to > change the header and moves the chunks around. Sorry, maybe I am a little bit confused but I do not understand what you mean. There is only one ifdef using CONFIG_PREEMPT_RT. This is required for compatibility to lower kernel versions to introduce newer CONFIG_PREEMPT_RT_FULL. All other code parts are using CONFIG_PREEMPT_RT_FULL afterwards. > Also, I believe the hunk is still wrong, it replaces: > #define DEFINE_BINARY_SEMAPHORE(sem) DEFINE_SEMAPHORE(sem, 1) > with: > #define DEFINE_BINARY_SEMAPHORE(sem) DEFINE_SEMAPHORE(sem) Your are right, that's true! In newer kernel version DEFINE_SEMAPHORE does accept only one argument. But I am not sure why and in which version. So I will check how to do here. Regards, Christoph _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
