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

[Jeff Johnston <jjohnstn at redhat dot com>]

On 03/31/2010 12: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)
>
> sys/types.h includes sys/sched.h.
>
> I think sys/sched.h exists to allow ports to override
> the constants and structure definitions. If this is
> right, it is not included for inclusion by applications
> directly.

It is akin to the bits directory used by glibc for platform specific 
values but not sure it started that way in newlib's infancy.

For example, glibc sched.h has the prototypes for the sched functions in 
it and includes bits/sched.h which contains essentially what we 
currently have in sys/sched.h.

If a system isn't happy with the newlib definition, it overrides 
sys/sched.h with its own.

> I am giving history the benefit of the doubt that this
> is all done for a reason and correctly placed. Someone
> else will need to confirm that.


> > * 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?

According to the ChangeLog you added it on 2000-02-11. :)

Newlib was ANSI C 90 plus extensions so it probably got put there since 
we stuck additional types there for the most part.

That said, if timespec were instead placed in sys/time.h and could be 
accessed via a __need_timespec flag (with #include <machine/types.h> and 
time_t definition if needed), then sys/sched.h would require sys/time.h 
with the __need_timespec flag and no sys/types.h, sys/types.h would 
require sys/sched.h (where needed) to get struct sched_param.  That 
could also be put under a __need_sched_param flag.

I believe that would remove the circular dependency that Ralf noticed. 
Have I missed something?

-- Jeff J.

> --joel
> > Ralf