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
