sys/sched.h and RTEMS

[Ralf Corsepius]

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