[Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Jan Kiszka]

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. Or would the feature check prevent that Xenomai
threads of a non-SMP application are scheduled on multiple CPUs?

However, to improve user experience, let's invert the default.

---
 ChangeLog      |    4 ++++
 README.INSTALL |    2 +-
 configure.in   |    6 +++---
 3 files changed, 8 insertions(+), 4 deletions(-)

Index: b/ChangeLog
===================================================================
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2008-08-22  Jan Kiszka  <jan.kiszka@domain.hid>
+
+	* configure.in: Enable SMP support by default.
+
 2008-08-21  Philippe Gerum  <rpm@xenomai.org>
 
 	* ksrc/nucleus/pipe.c (xnpipe_write): Fix inverted O_SYNC
Index: b/configure.in
===================================================================
--- a/configure.in
+++ b/configure.in
@@ -131,12 +131,12 @@ AC_ARG_ENABLE(debug,
 	esac])
 AC_MSG_RESULT(${debug_symbols:-no})
 
-dnl SMP support (default: off)
+dnl SMP support (default: on)
 
-CONFIG_SMP=
+CONFIG_SMP=y
 AC_MSG_CHECKING(for SMP support)
 AC_ARG_ENABLE(smp,
-	AS_HELP_STRING([--enable-smp], [Enable SMP support]),
+	AS_HELP_STRING([--disable-smp], [Disable SMP support (if the target supports it at all)]),
 	[case "$enableval" in
 	y | yes) CONFIG_SMP=y ;;
 	*) unset CONFIG_SMP ;;
Index: b/README.INSTALL
===================================================================
--- a/README.INSTALL
+++ b/README.INSTALL
@@ -143,7 +143,7 @@ NAME                 DESCRIPTION
 
 --prefix             Installation directory          /usr/xenomai
 --enable-debug       Enable debug symbols (-g)       disabled
---enable-smp         Enable SMP support              weak,disabled
+--disable-smp        Disable SMP support             weak,enabled
 
 1.3.3 Arch-specific configure options
 -------------------------------------

Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Gilles Chanteperdrix]

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.

-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Jan Kiszka]

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.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Gilles Chanteperdrix]

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 ?

-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Jan Kiszka]

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. ]

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Gilles Chanteperdrix]

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
enabled.

You mean we should include asm/xenomai/features.h before using CONFIG_SMP ?

-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> 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
> enabled.
> 
> You mean we should include asm/xenomai/features.h before using CONFIG_SMP ?

That helps as well - I added xeno_config.h explicitly so far, but
features.h implies xeno_config.h, of course.

Jan - who seems to have run into alignment issues of cmpxchg on x86_64

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> 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
>> enabled.
>>
>> You mean we should include asm/xenomai/features.h before using CONFIG_SMP ?
> 
> That helps as well - I added xeno_config.h explicitly so far, but
> features.h implies xeno_config.h, of course.

asm/xenomai/features.h does convert the configure.in options into the
kernel "namespace" options. But it seems that CONFIG_SMP is directly set
by configure.in anyway.

> Jan - who seems to have run into alignment issues of cmpxchg on x86_64

pthread_mutex_lock uses xnheap_alloc to allocate the piece of memory
used for the mutex. So, if the piece of memory is not eight bytes
aligned, this is xnheap_alloc's fault...

-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> 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
>>> enabled.
>>>
>>> You mean we should include asm/xenomai/features.h before using CONFIG_SMP ?
>> That helps as well - I added xeno_config.h explicitly so far, but
>> features.h implies xeno_config.h, of course.
> 
> asm/xenomai/features.h does convert the configure.in options into the
> kernel "namespace" options. But it seems that CONFIG_SMP is directly set
> by configure.in anyway.
> 
>> Jan - who seems to have run into alignment issues of cmpxchg on x86_64
> 
> pthread_mutex_lock uses xnheap_alloc to allocate the piece of memory
> used for the mutex. So, if the piece of memory is not eight bytes
> aligned, this is xnheap_alloc's fault...

Maybe it's far simpler: XNARCH_HAVE_US_ATOMIC_CMPXCHG - where the heck
does this come from? I just thought I only forgot to define it for
x86_64, but I don't find any traces for 32-bit as well. Hmm, should this
be called "CONFIG_XENO_FASTSEM" now? Testing...

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> 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
>>>> enabled.
>>>>
>>>> You mean we should include asm/xenomai/features.h before using CONFIG_SMP ?
>>> That helps as well - I added xeno_config.h explicitly so far, but
>>> features.h implies xeno_config.h, of course.
>> asm/xenomai/features.h does convert the configure.in options into the
>> kernel "namespace" options. But it seems that CONFIG_SMP is directly set
>> by configure.in anyway.
>>
>>> Jan - who seems to have run into alignment issues of cmpxchg on x86_64
>> pthread_mutex_lock uses xnheap_alloc to allocate the piece of memory
>> used for the mutex. So, if the piece of memory is not eight bytes
>> aligned, this is xnheap_alloc's fault...
> 
> Maybe it's far simpler: XNARCH_HAVE_US_ATOMIC_CMPXCHG - where the heck
> does this come from? I just thought I only forgot to define it for
> x86_64, but I don't find any traces for 32-bit as well. Hmm, should this
> be called "CONFIG_XENO_FASTSEM" now? Testing...

Yes, XNARCH_HAVE_US_ATOMIC_CMPXCHG is dead now, it was replaced with
CONFIG_XENO_FASTSEM.
CONFIG_XENO_FASTSEM, in turn is set by Kconfig in kernel space, and
configure.in in user-space.


-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> 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
>>>>> enabled.
>>>>>
>>>>> You mean we should include asm/xenomai/features.h before using CONFIG_SMP ?
>>>> That helps as well - I added xeno_config.h explicitly so far, but
>>>> features.h implies xeno_config.h, of course.
>>> asm/xenomai/features.h does convert the configure.in options into the
>>> kernel "namespace" options. But it seems that CONFIG_SMP is directly set
>>> by configure.in anyway.
>>>
>>>> Jan - who seems to have run into alignment issues of cmpxchg on x86_64
>>> pthread_mutex_lock uses xnheap_alloc to allocate the piece of memory
>>> used for the mutex. So, if the piece of memory is not eight bytes
>>> aligned, this is xnheap_alloc's fault...
>> Maybe it's far simpler: XNARCH_HAVE_US_ATOMIC_CMPXCHG - where the heck
>> does this come from? I just thought I only forgot to define it for
>> x86_64, but I don't find any traces for 32-bit as well. Hmm, should this
>> be called "CONFIG_XENO_FASTSEM" now? Testing...
> 
> Yes, XNARCH_HAVE_US_ATOMIC_CMPXCHG is dead now, it was replaced with
> CONFIG_XENO_FASTSEM.
> CONFIG_XENO_FASTSEM, in turn is set by Kconfig in kernel space, and
> configure.in in user-space.
> 

Then this should fix fastsem support again (still preparing the
test...):

---
 ksrc/skins/posix/mutex.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

Index: b/ksrc/skins/posix/mutex.c
===================================================================
--- a/ksrc/skins/posix/mutex.c
+++ b/ksrc/skins/posix/mutex.c
@@ -97,11 +97,11 @@ int pse51_mutex_init_internal(struct __s
 	shadow->mutex = mutex;
 	shadow->lockcnt = 0;
 
-#ifdef XNARCH_HAVE_US_ATOMIC_CMPXCHG
+#ifdef CONFIG_XENO_FASTSEM
 	xnarch_atomic_set(&shadow->lock, -1);
 	shadow->attr = *attr;
 	shadow->owner_offset = xnheap_mapped_offset(&sys_ppd->sem_heap, ownerp);
-#endif /* XNARCH_HAVE_US_ATOMIC_CMPXCHG */
+#endif /* CONFIG_XENO_FASTSEM */
 
 	if (attr->protocol == PTHREAD_PRIO_INHERIT)
 		synch_flags |= XNSYNCH_PIP;
@@ -163,16 +163,16 @@ int pthread_mutex_init(pthread_mutex_t *
 		goto checked;
 
 	err = pse51_mutex_check_init(shadow, attr);
-#ifndef XNARCH_HAVE_US_ATOMIC_CMPXCHG
+#ifndef CONFIG_XENO_FASTSEM
 	cb_read_unlock(&shadow->lock, s);
 	if (err)
 		return -err;
-#else /* XNARCH_HAVE_US_ATOMIC_CMPXCHG */
+#else /* CONFIG_XENO_FASTSEM */
 	if (err) {
 		cb_read_unlock(&shadow->lock, s);
 		return -err;
 	}
-#endif /* XNARCH_HAVE_US_ATOMIC_CMPXCHG */
+#endif /* CONFIG_XENO_FASTSEM */
 
   checked:
 	mutex = (pse51_mutex_t *) xnmalloc(sizeof(*mutex));

Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> 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
>>>>>> enabled.
>>>>>>
>>>>>> You mean we should include asm/xenomai/features.h before using CONFIG_SMP ?
>>>>> That helps as well - I added xeno_config.h explicitly so far, but
>>>>> features.h implies xeno_config.h, of course.
>>>> asm/xenomai/features.h does convert the configure.in options into the
>>>> kernel "namespace" options. But it seems that CONFIG_SMP is directly set
>>>> by configure.in anyway.
>>>>
>>>>> Jan - who seems to have run into alignment issues of cmpxchg on x86_64
>>>> pthread_mutex_lock uses xnheap_alloc to allocate the piece of memory
>>>> used for the mutex. So, if the piece of memory is not eight bytes
>>>> aligned, this is xnheap_alloc's fault...
>>> Maybe it's far simpler: XNARCH_HAVE_US_ATOMIC_CMPXCHG - where the heck
>>> does this come from? I just thought I only forgot to define it for
>>> x86_64, but I don't find any traces for 32-bit as well. Hmm, should this
>>> be called "CONFIG_XENO_FASTSEM" now? Testing...
>> Yes, XNARCH_HAVE_US_ATOMIC_CMPXCHG is dead now, it was replaced with
>> CONFIG_XENO_FASTSEM.
>> CONFIG_XENO_FASTSEM, in turn is set by Kconfig in kernel space, and
>> configure.in in user-space.
>>
> 
> Then this should fix fastsem support again (still preparing the
> test...):

Yes, please commit.

-- 
                                                 Gilles.