lkml.org 
[lkml]   [2011]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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


    \
     
     \ /
      Last update: 2011-05-10 13:45    [W:3.325 / U:1.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site