Re: candidate sched.h and sys/sched.h for review

[Ralf Corsepius <ralf dot corsepius at rtems dot org>]

On 03/31/2010 06:22 PM, Joel Sherrill wrote:
> On 03/31/2010 10:08 AM, Ralf Corsepius wrote:
> > On 03/31/2010 04:54 PM, Joel Sherrill wrote:
> > > Next try.  I am starting a build with this now so there
> > > might be problems.
> > >
> > > Corinna.. SCHED_SPORADIC is now 4. My concern is
> > > with these constants is that they are sometimes used
> > > in language bindings and we would have to propagate that.
> > > If you don't mind, once this rework is in, I will address
> > > getting us in sync on the other values.
> > >
> > > How does it look now?
> > Errm, I don't think so:
> >
> > * Shouldn't sched.h include sys/sched.h?
> > * Why does sys/sched.h exist at all?
> >     Shouldn't it better be merged into sched.h?
> newlib is rather contorted here but I think it
> gets the job done.
>
> sched.h includes sys/types.h (which defines timespec)
SUSv4 mandates timespec in <time.h> and sys/sched.h to receive it from 
<time.h>.

The fact that it might be indirectly specified elsewhere is not actually 
of importance.
> sys/types.h includes sys/sched.h.

I would not want to call this a proper implementation.

> I think sys/sched.h exists to allow ports to override
> the constants and structure definitions.
I am inclined to agree. Whether this is useful is a different question.

> > * Shouldn't sys/sched.h include<time.h>  (for timespec)?
> timespec is in sys/types.h which is included by sched.h.
>
> Can someone through some light on this?
IMO, your implementation is not clean, but relies on historic artifacts 
in newlib.

Ralf