Re: Patch - Add pthread affinity for RTEMS

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

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:
>>>>>> 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.
> 
> 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
application.)
 * This permission is first granted in 2008, but use it for older ones,
also.
 * Allow for _XOPEN_SOURCE to be empty (from the earliest form of it,
before 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,
and __BSD_VISIBLE.

We are just asking to add a trip for __GNU_VISIBLE and use
it.

==============================
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
time?

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.

> 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