This is the mail archive of the
mailing list for the newlib project.
- From: Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- To: newlib at sourceware dot org
- Date: Mon, 15 Jul 2013 12:13:36 +0200
- Subject: Re: pthread.h
- References: <f5qchu8cm5v3nh4104qinwms dot 1372951564676 at email dot android dot com> <20130705091931 dot GD4009 at calimero dot vinschen dot de> <51DAEF9B dot 8060901 at rtems dot org>
On 07/08/2013 06:58 PM, Ralf Corsepius wrote:
On 07/05/2013 11:19 AM, Corinna Vinschen wrote:
On Jul 4 10:26, Joel Sherrill wrote:
Following up.. In general what should be done about adding np methods?
All of the thread affinity services are beyond POSIX at this point add
is getting the pthread attributes. As we consider adding these
methods, what is the guidance?
I think there's not much speaking against adding _np functions if their
declaration is guarded by !_POSIX_SOURCE or _GNU_SOURCE.
Just picking up this mail from this torn apart thread, to reply:
The more I think about newlib's pthread.h, the more I think it should be
removed from newlib rsp. moved into newlib's rtems/ directory, because I
believe nobody but RTEMS uses it.
 Grepping the source tree tells, the cris port also seems to use it, but I
am inclined to believe this to be a bug, because I am having difficulties to
imagine what a bare-metal target would need pthread.h for.
 IIRC, bootstrapping GCC also requires for targets which actually support
pthreads. For newlib, to my knowledge this would be cygwin and RTEMS, only.
How do we want to proceed with this?
1. Move "newlib/libc/include/pthread.h" to "?".
2. Perform RTEMS specific updates of pthread.h?
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : firstname.lastname@example.org
PGP : Public key available on request.
Diese Nachricht ist keine geschÃftliche Mitteilung im Sinne des EHUG.