Re: [Xenomai-core] Fast userspace locks for native skin
Jan Kiszka wrote: Gilles Chanteperdrix wrote: decision (we could store the first pending thread priority in a user/kernel shared area, with the complication that we would need updating this priority if it ever changes, but to get the priority of the current thread, we also need a syscall, moreover switching to secondary mode). I'm not thinking about the case where there is already someone waiting. That will need a kernel entry anyway (the low-prio waiter may sit on some other CPU...). But in case signaling always happens before pending, there is no need at all to consult the kernel. In this case, you can avoid calling pthread_cond_signal at all... So, if you are stupid enough to call pthread_cond_signal when no-one is waiting, you deserve a syscall anyway. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Fast userspace locks for native skin
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: decision (we could store the first pending thread priority in a user/kernel shared area, with the complication that we would need updating this priority if it ever changes, but to get the priority of the current thread, we also need a syscall, moreover switching to secondary mode). I'm not thinking about the case where there is already someone waiting. That will need a kernel entry anyway (the low-prio waiter may sit on some other CPU...). But in case signaling always happens before pending, there is no need at all to consult the kernel. In this case, you can avoid calling pthread_cond_signal at all... So, if you are stupid enough to call pthread_cond_signal when no-one is waiting, you deserve a syscall anyway. Yes, algorithmically avoidable. OK, let's see if there is someone who actually has a need for it (legacy code...). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
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 [EMAIL PROTECTED]
+
+ * configure.in: Enable SMP support by default.
+
2008-08-21 Philippe Gerum [EMAIL PROTECTED]
* 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-smpDisable SMP support weak,enabled
1.3.3 Arch-specific configure options
-
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
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));
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH 1/2] Add x86_64 fastsem support
As the subject says. Passed your unit_mutex test, nothing else tried
yet, weekend is calling.
---
configure.in|1 +
include/asm-x86/atomic_64.h | 31 +--
ksrc/arch/x86/Kconfig |2 +-
3 files changed, 31 insertions(+), 3 deletions(-)
Index: b/configure.in
===
--- a/configure.in
+++ b/configure.in
@@ -103,6 +103,7 @@ case $host in
XENO_TARGET_ARCH=x86
XENO_LINUX_ARCH=x86_64
XENO_LINUX_INSTALL_TARGET=install
+ CONFIG_XENO_FASTSEM=y
;;
*) echo
echo ***
Index: b/include/asm-x86/atomic_64.h
===
--- a/include/asm-x86/atomic_64.h
+++ b/include/asm-x86/atomic_64.h
@@ -21,6 +21,10 @@
#define _XENO_ASM_X86_ATOMIC_64_H
#define _XENO_ASM_X86_ATOMIC_H
+#include asm/xenomai/features.h
+
+typedef unsigned long atomic_flags_t;
+
#ifdef __KERNEL__
#include linux/bitops.h
@@ -50,10 +54,20 @@ typedef atomic64_t xnarch_atomic_t;
#else /* !__KERNEL__ */
-#include asm/xenomai/features.h
+#ifdef CONFIG_SMP
+#define LOCK_PREFIX lock ;
+#else
+#define LOCK_PREFIX
+#endif
+
+typedef struct { unsigned long counter; } xnarch_atomic_t;
#define __xeno_xg(x) ((volatile long *)(x))
+#define xnarch_atomic_get(v) ((v)-counter)
+
+#define xnarch_atomic_set(v,i) (((v)-counter) = (i))
+
static inline unsigned long xnarch_atomic_xchg (volatile void *ptr,
unsigned long x)
{
@@ -64,12 +78,25 @@ static inline unsigned long xnarch_atomi
return x;
}
+static inline unsigned long
+xnarch_atomic_cmpxchg(xnarch_atomic_t *v, unsigned long old, unsigned long
newval)
+{
+ volatile void *ptr = v-counter;
+ unsigned long prev;
+
+ __asm__ __volatile__(LOCK_PREFIX cmpxchgq %1,%2
+: =a(prev)
+: r(newval), m(*__xeno_xg(ptr)), 0(old)
+: memory);
+ return prev;
+}
+
#define xnarch_memory_barrier()asm
volatile(mfence:::memory)
#define xnarch_read_memory_barrier() asm volatile(lfence:::memory)
#define xnarch_write_memory_barrier() xnarch_memory_barrier()
#endif /* __KERNEL__ */
-typedef unsigned long atomic_flags_t;
+#include asm-generic/xenomai/atomic.h
#endif /* !_XENO_ASM_X86_ATOMIC_64_H */
Index: b/ksrc/arch/x86/Kconfig
===
--- a/ksrc/arch/x86/Kconfig
+++ b/ksrc/arch/x86/Kconfig
@@ -4,7 +4,7 @@ config XENO_GENERIC_STACKPOOL
config XENO_FASTSEM
bool
- default y if X86_32
+ default y
source kernel/xenomai/nucleus/Kconfig
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/2] Add x86_64 fastsem support
Jan Kiszka wrote: As the subject says. Passed your unit_mutex test, nothing else tried yet, weekend is calling. Ok for me. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 2/2] Unify asm-x86/atomic.h
Jan Kiszka wrote: ...and also automatically fixes the missing LOCK prefix for pthread_mutex_* services on x86_32 SMP. This looks to me as a half-way unification. Can we not totally get rid of atomic_32.h and atomic_64.h ? I mean since we are using unsigned long as atomic_t on both platforms, there should not be much difference (except maybe the inline asm). -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
