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

Reply via email to