This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Patch - Add pthread affinity for RTEMS
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: newlib at sourceware dot org
- Date: Sat, 23 Nov 2013 16:42:47 -0600
- Subject: Re: Patch - Add pthread affinity for RTEMS
- Authentication-results: sourceware.org; auth=none
- References: <528F6A68 dot 1070607 at oarcorp dot com> <528F6F2B dot 3060600 at embedded-brains dot de> <528FAE64 dot 8020907 at oarcorp dot com> <20131123213949 dot GB2283 at calimero dot vinschen dot de>
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