Patch - Add pthread affinity for RTEMS
Sat Nov 23 22:43:00 GMT 2013
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:
>>>> 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
In this case, this is a GNU extension and is intentionally so.
If we just mark it with __rtems__, we are not following glibc.
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
More information about the Newlib