This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch - Add pthread affinity for RTEMS


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?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: pgprGFgExDt8p.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]