candidate sched.h and sys/sched.h for review
Wed Mar 31 21:16:00 GMT 2010
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
>> 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.
>> -- Jeff J.
More information about the Newlib