This is the mail archive of the
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: Tue, 26 Nov 2013 14:04:16 -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> <52912F67 dot 4010406 at oarcorp dot com> <20131125100708 dot GC19584 at calimero dot vinschen dot de>
On 11/25/2013 4:07 AM, Corinna Vinschen wrote:
> On Nov 23 16:42, Joel Sherrill wrote:
>> 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
> I'm all for defining a formal feature macro system in features.h, but...
>> In this case, this is a GNU extension and is intentionally so.
>> If we just mark it with __rtems__, we are not following glibc.
> ...we didn't set this detailed system up yet. What I'm trying to
> say is just this. Shouldn't we fist make sure to set up our formal
> feature test macro system in features.h and only then introduce the
> newly defined macros?
OK. features.h has pretty thorough POSIX features for RTEMS,
XMK, and Cygwin. There is an svr4 define which I don't know
what trips. But the bottom section has this comment:
/* Per the permission given in POSIX.1-2008 section 2.2.1, define
* _POSIX_C_SOURCE if _XOPEN_SOURCE is defined and _POSIX_C_SOURCE is not.
* (_XOPEN_SOURCE indicates that XSI extensions are desired by an
* This permission is first granted in 2008, but use it for older ones,
* Allow for _XOPEN_SOURCE to be empty (from the earliest form of it,
* was required to have specific values).
I take that to mean _POSIX_C_SOURCE and _XOPEN_SOURCE
can be used or derived from.
features.h doesn't look in too bad of a shape. cdefs.h is
from FreeBSD and interprets those and gives us
___XSI_VISIBLE, __POSIX_VISIBLE, __ISO_C_VISIBLE,
We are just asking to add a trip for __GNU_VISIBLE and use
If we can't come to general agreement that the features.h
provides everything we need except __GNU_VISIBLE, then
how do we deal with this one case at this one point in
I am all for general improvements but RTEMS needs the
affinity APIs now.
Help us find a suitable way to add these. :)
And if that involves a plan to use the __XXX_VISIBLE flags
more, then so be it. Let's define a plan to do that.
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