Re: [PATCH] wait: include linux/sched.h

From: Ingo Molnar
Date: Fri May 06 2011 - 03:54:23 EST



* Kaywinnit L. Frye <kaywinnit.lee.frye.2497@xxxxxxxxx> wrote:

> signal_pending(), schedule*() and TASK_* are used in various macros in
> wait.h and all defined in linux/sched.h
>
> Cc: Michal Nazarewicz <m.nazarewicz@xxxxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxx>
> Cc: Greg Kroah-Hartman <gregkh@xxxxxxx>
> Cc: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
> Cc: Evgeny Kuznetsov <EXT-Eugeny.Kuznetsov@xxxxxxxxx>
> Cc: linux-kernel@xxxxxxxxxxxxxxx
> Signed-off-by: Kaywinnit L. Frye <kaywinnit.lee.frye.2497@xxxxxxxxx>
> ---
> include/linux/wait.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/wait.h b/include/linux/wait.h
> index 3efc9f3..667a3d7 100644
> --- a/include/linux/wait.h
> +++ b/include/linux/wait.h
> @@ -22,6 +22,7 @@
> #include <linux/list.h>
> #include <linux/stddef.h>
> #include <linux/spinlock.h>
> +#include <linux/sched.h>
> #include <asm/system.h>
> #include <asm/current.h>

I'm quite sure this will break the build all around the place, because sched.h
itself uses wait.h primitives.

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 from higher level helper methods (which inevitably mix different
domains) and put them into two separate files.

We have a few such split files in the kernel tree, spinlock_types.h and
spinlock_api.h, and this concept works reasonably well.

So here we'd need wait_types.h and wait_api.h and of course sched_types.h and
sched_api.h.

For simplicity of migration wait_api.h could be wait.h itself and sched_api.h
could be sched.h itself.

That way we'd stop the exponential explosion of header file inter-dependencies
at its source and would create a clean hierarchy of data types (the *_types.h
files, which never include *_api.h files), plus the real *_api.h files that .c
files would use.

As a result we'd probably have faster build times and we could also remove a
lot of CPP macro hell which is currently used to work around dependency
spaghetti bugs.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/