Re: sys/sched.h and RTEMS

[Corinna Vinschen <vinschen at redhat dot com>]

On Feb  6 22:00, Ralf Corsepius wrote:
> Corinna Vinschen wrote:
>> On Feb  6 13:55, Joel Sherrill wrote:
>>> 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)

Even worse, the definitions in Cygwin's sched.h and the definitions
in newlib's sched.h don't match at all.  So if somebody uses sys/sched.h
on Cygwin explicitely, he or she's screwed.  If the file isn't referenced
explicitely it's fortunately never referenced by any other header on Cygwin.

Considering the situation, I guess I would prefer to move sched.h to the
spu subdir and to keep the non-newlib versions of sched.h in RTEMS and
Cygwin as they are.  I will also create another sys/sched.h in Cygwin
which implicitely overrides the newlib sys/sched.h when installing from
source.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat