Patch - Add pthread affinity for RTEMS

[Corinna Vinschen]

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.

> 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.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20131127/992f5b01/attachment.sig>