Messages in this thread | | | Date | Tue, 10 May 2011 13:42:17 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] wait: include linux/sched.h |
| |
* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Tue, 2011-05-10 at 12:36 +0200, Ingo Molnar wrote: > > > > Obviously sched.h would include a lot of basic types to begin with, because it > > is a fundamental 'container' type (struct task_struct) sitting at a top, > > highlevel node of the type hierarchy - so the initial step you suggest would > > indeed get us most of the benefits. > > I very well understand the whole header mess, and in particular last time I > looked at the sched.h vs wait.h thing simply removing the non sched.c related > things was enough to resolve this particular problem.
No!
The wait.h problem is this: why do we want to include sched.h in wait.h?
We do not want it:
- the waitqueue definitions do not need it - the main waitqueue accessor methods do not need it
types using waitqueues should not need to include sched.h as well - directly or indirectly!
Why does wait.h 'need' sched.h to work standalone right: because a few convenience helper functions in wait.h use scheduler functionality and scheduler constants.
As a result of this mess much of wait.h is written in hard to read 1970's tech: in the C preprocessor macro language.
Note that even *those* helpers do not really need to know the layout of struct task_struct (about which most of sched.h's complexity is): they only need to know the task state bits and a few scheduler API methods related to the concept of scheduling/waiting.
And note in that context it very much makes sense to have wait_types.h and wait_api.h (wait.h): all the derivative types that use waitqueues do not need all the helper functions like wait_event() and do not need to include scheduler lowlevel context switching details ... Only .c files that *use* waitqueues need to include the full kit.
But even the first step of purifying the headers will be a big step forward.
> I really don't like the foo_type.h headers much and think we should only use > them as absolute last resort solutions.
I understood your point as cleaning up sched.h to be able to include sched.h in wait.h and with that solution i disagree violently: sched.h is about struct task_struct and wait.h does not need that - nor do the dozens of other types need it that use waitqueues.
We can move all the task definitions and APIs from sched.h into wait.h then yes that's the first good first step toward purer structure for both sched.h and wait.h.
We can also move signal bits into a separate header, to streamline sched.h some more - but sched.h will always be a 'container' kind of super-header, by its very nature.
Or if you want some other structure for it all then please outine that structure. We could certainly move struct task_struct definition into a separate task.h and keep all context switch related definitions in sched.h.
Then task.h will need to be included in tons of code that dereferences 'current' directly. So for pragmatic reasons it's probably better to keep struct task_struct in sched.h. But we can do the more complex change as well, as long as there's a plan behind it and as long as there's someone doing it ;-)
> I might have mis-read your email, but to me your: > > "To fix these super-headers like sched.h and to make wait.h > self-sufficient the right and cleanest approach would be to split data > types and primitive accessor functions.." > > Seems to suggest to begin with that split, instead of starting with sane > cleanups like moving the signal and process (groups of tasks) bits out > into their own headers.
Yeah. Either direction is fine to me and moving out unrelated stuff sure is the bulk of the work.
Thanks,
Ingo
| |