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

[Ralf Corsepius]

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