Patch - Add pthread affinity for RTEMS
Joel Sherrill
joel.sherrill@oarcorp.com
Wed Nov 27 20:14:00 GMT 2013
On 11/27/2013 4:28 AM, Corinna Vinschen wrote:
> On Nov 26 14:04, Joel Sherrill wrote:
>> 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:
>>>>> 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.
>
> This is pretty new. I hadn't taken in that we have this stuff for
> a few months now and I expected it in features.h, as in glibc,
> rather than in sys/cdefs.h as on BSD. Oh well.
newlib is more BSD source so it makes sense to follow BSD internally
but present a public side that provides as much glibc compatibility
as needed.
FWIW these were added by Sebastian and I over time as part of
updating our FreeBSD TCP/IP stack and his porting the FreeBSD
USB stack to RTEMS. We use a LOT of BSD code for higher level
services. But we also have code like JFFS2. So we need .h files
that bridge the worlds.
>> We are just asking to add a trip for __GNU_VISIBLE and use it.
>
> Well, sure. __GNU_VISIBLE is an internal macro, though. We should
> add a _GNU_SOURCE enabling expression in sys/cdefs.h as well.
> AFAICS it should be something like everything else plus
> __GNU_VISIBLE:
>
> #if defined(_GNU_SOURCE) #define __POSIX_VISIBLE 200809
> #define __XSI_VISIBLE 700 #define __BSD_VISIBLE
> 1 #define __ISO_C_VISIBLE 2011 #define __GNU_VISIBLE
> 1
>
> I'm just not sure where exactly to add it. In theory it should
> override all other choices except _POSIX_C_SOURCE, maybe.
That seems to match the intent of glibc's features.h. It turns on
the everything and the kitchen sink. AFAIK that's all the
__XXX_VISIBLE flags newlib has.
We will update the patch to expand that area in cdefs.h and turn
the patch around for review.
Sorry for the trouble.
Thanks.
> 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
More information about the Newlib
mailing list