Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Disabling SMP (on platforms where this isn't off by design already) is
>>>>> an optimization. In contrast, not enabling it by default is doomed to
>>>>> cause problems for users that run ./configure without looking into each
>>>>> and every switch - now that CONFIG_SMP is very important for all the
>>>>> fast locking stuff.
>>>> I would consider setting CONFIG_SMP by default on x86... because on some
>>>> other architectures like arm, it is not even yet a valid configuration.
>>> But it is on PowerPC or IA64. Would it cause troubles for the
>>> non-SMP-ready archs? Then we can disable it on those selectively.
>> Are you sure that the lock prefix on an UP x86 or lsync on an UP powerpc
>> is hamrless ?
> LOCK is harmless (except for potential overhead), can't comment isync,
> but I strongly suspect the same (locking at the glibc e.g.). There is a
> simple idea behind this: Do you have to install a special glibc in order
> to enable/disable SMP support?
> [ BTW, I think the current pthread_mutex implementation lacks the LOCK
> prefix even in SMP mode due to include issues. Will get fixed with my
> patches under preparation, which also unifies that stuff on x86. ]
Should be easy to check, disassemble pthread_mutex_lock with CONFIG_SMP
You mean we should include asm/xenomai/features.h before using CONFIG_SMP ?
Xenomai-core mailing list