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: Wed, 27 Nov 2013 09:02: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> <5294FEC0 dot 9090504 at oarcorp dot com> <20131127102822 dot GA2449 at calimero dot vinschen dot de>
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.
>>>> 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
>>> ...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
>> 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
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
> #if defined(_GNU_SOURCE) #define __POSIX_VISIBLE 200809
> #define __XSI_VISIBLE 700 #define __BSD_VISIBLE
> 1 #define __ISO_C_VISIBLE 2011 #define __GNU_VISIBLE
> 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.
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