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

[Joel Sherrill]

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.
>    
Ok.  I will do that and make sure it can build RTEMS.
> 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.
>    
If it works, it is fine with me. Just distinct surgery from this.


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


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985