This is the mail archive of the 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 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,
> 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
> #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.


> Corinna

Joel Sherrill, Ph.D.             Director of Research & Development        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

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