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

[Jeff Johnston]

On 03/31/2010 04:14 PM, Joel Sherrill wrote:
> On 03/31/2010 01:56 PM, Jeff Johnston wrote:
>> 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.. should the movement of timespec be done as part of
> this patch or a follow up?
>

Well, there are issues with the patch as-is.

sched.h should include sys/sched.h as it has in the past and is done in 
the glibc model.  The inclusion of sys/types.h-only does not work for 
me.  sys/types.h only includes sys/sched.h when _POSIX_THREADS is 
defined.  AFAIK, struct sched_param definition by sched.h is not tied to 
_POSIX_THREADS being defined.

If everyone is ok with my proposal for getting rid of the circular 
dependency, I can do it after you modify your patch to essentially be 
prototypes added to sched.h.

-- Jeff J.

> --joel
>> -- Jeff J.
>>
>>> --joel
>>>> Ralf
>>>
>
>