Re: pthread.h

[Sebastian Huber <sebastian dot huber at embedded-brains dot de>]

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[1][2].
>
> Ralf
>
> [1] 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.
>
> [2] 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  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschÃftliche Mitteilung im Sinne des EHUG.