Patch - Add pthread affinity for RTEMS

[Joel Sherrill]

On 11/23/2013 3:39 PM, Corinna Vinschen wrote:
> On Nov 22 13:20, Joel Sherrill wrote:
>> On 11/22/2013 8:50 AM, Sebastian Huber wrote:
>>> On 2013-11-22 15:30, Joel Sherrill wrote:
>>>> Hi
>>>> 
>>>> This patch follows up on the recent addition of the RTEMS
>>>> specific cpuset.h and adds GNU/Linux style pthread affinity
>>>> APIs to pthread.h.
>>>> 
>>>> Sebastian.. we think the guards follow your recommendations.
>> 
>> Jennifer thinks I grabbed the version before your
>> recommendation. More below. [...]
>>>> +#if defined(__USE_GNU) && defined(__rtems__)
>>> 
>>> I would rather use
>>> 
>>> #ifdef _GNU_SOURCE
>> 
>> This is translated to "__USE_GNU" in <sys/cdefs.h> in the new
>> version and the guard on specific code blocks is "__USE_GNU". I
>> think this is what you and Corinna suggested.
> 
> We don't actually utilize _GNU_SOURCE or __USE_GNU in newlib so
> far, except in libc/sys/linux.  We just don't have the detailed
> features.h in place as glibc has.  What we really have is
> _POSIX_SOURCE and __STRICT_ANSI__, and a teensy little bit of
> __XSI_VISIBLE, __POSIX_VISIBLE and __BSD_VISIBLE.  The last three
> are only rarely used, and we shouldn't start using them or others
> more often, unless we have the matching feature test macros defined
> in features.h along the lines (but not necessarily identical to)
> glibc.  IMHO.

Unfortunately, these really are the glibc APIs and provided to
increase compatibility between RTEMS and GNU/Linux.

I would like to see us move more to the feature macros and away
from the list of OSes we have now. I know it is a lot of details
though.

In this case, this is a GNU extension and is intentionally so.
If we just mark it with __rtems__, we are not following glibc.

> Corinna
> 



-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985