This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]