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

[Jeff Johnston]

On 03/31/2010 05:22 PM, Joel Sherrill wrote:
> One last question to make sure I have it right.
>
> sys/sched.h needs timespec.
>
> What file is best to include?
> Does sched.h or sys/sched.h include that file?
>

Currently, timespec is in sys/types.h. Your sched.h currently includes 
sys/types.h to get pid_t.  I think you should leave that include as-is 
and also include sys/sched.h.  Currently, sys/sched.h includes 
sys/types.h as well, but after my change, it should end up including 
something other than sys/types.h to get timespec (either time.h or 
sys/_time.h) so rather than me having to change sched.h afterwards, just 
include it now.

-- Jeff J.

> --joel
>
> On 03/31/2010 04:10 PM, Jeff Johnston wrote:
>> 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
>>>
>
>