This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: sys/sched.h and RTEMS
Corinna Vinschen wrote:
On Feb 6 13:55, Joel Sherrill wrote:
Hi,
Ralf noticed that the newlib sched.h and RTEMS
sched.h are conflicting and we wondered what
you all thought was the best solution.
If we do that, I think RTEMS can delete its sched.h
and we can get back to only one copy.
What do you all think?
A quick and dirty work around for us is to replace newlib's sched.h.
On a wider scale I actually think newlib's sched.h should be removed
from newlib or be moved to some spu specific directory (likely in
libgloss), because it seems to have been added by an spu specific patch:
>2007-09-21 Patrick Mansfield <patmans@us.ibm.com>
>
> * libc/include/sched.h: New file, just include sys/sched.h.
> * libc/machine/spu/sys/sched.h: New file, has just sched_yield
> prototype.
Also corresponding to this observation:
sched.h isn't used by newlib itself at all (sys/sched.h is used).
Cygwin is currently using its own sched.h as well.
It's in the sourceware
repository under src/winsup/cygwin/include. If you're going to create a
unified version of sched.h, it would be nice to accommodate Cygwin, too.
Technically, merging the Cygwin version and the RTEMS version should not
be much of a problem, however this is somewhat problematic on RTEMS part:
Current RTEMS treats sched.h as a conditionally installed header, which
is only installed, if RTEMS is being built with its _optional_ "posix"
support activated.
(however RTEMS uses newlib's pthread.h unconditionally ... so
unconditionally having sched.h shouldn't be much of problem, either)
Ralf