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 Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core