[lkml]   [2009]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC,PATCH 14/14] utrace core
    > Could we just drop the tracehook layer if this finally merged
    > and call the low level functions directly?

    We can certainly do appropriate streamlining cleanups later, by all
    means. The original purpose of the tracehook layer is simply this:

    A person hacking on core kernel code or arch code should not have to
    think about all the innards of tracing (ptrace, utrace, or anything
    else). If he comes across a tracehook_* call, he can just read its
    kernel-doc for explanation of its parameters, return value, what it
    expects about its context (locking et al), and what the semantic
    significance of making that particular call is. If changes to the
    core/arch code in question do not require changing any of those
    aspects, then said person need not consider tracing issues further.
    If a change to a function's calling interface or contextual
    assumptions looks warranted, then he knows he should discuss the
    details with some tracing-related folks (i.e. find tracehook.h in
    MAINTAINERS and thus get to me and Oleg).

    Likewise, a person hacking on tracing code should not have to think
    about every corner of interaction with the core code or arch code.
    Each tracehook_* call's kernel-doc comments say everything that
    matters about how and where it's called. If some of those details
    are problematic for what we want to do inside the tracing code, then
    we know we have to hash out the details with the maintainers of the
    core or arch code that makes those calls. Otherwise we can keep our
    focus on tracing infrastructure without spending time getting lost
    in arcane details of the arch or core kernel code.

    These two things seem permanently worthwhile to me: that the core
    and arch source code use simple function calls without open-coding
    any innards of the tracing infrastructure; and that these functions
    have clear and complete documentation about their calling interfaces
    and context (locking et al). I find it natural and convenient that
    such calls have a common prefix that makes it obvious to any reader
    of the core code what subsystem the call relates to.

    Beyond those ideas, I certainly don't care at all what the names of
    these functions are, what common prefix is used, or in which source
    files those declarations and kernel-doc comments appear.


     \ /
      Last update: 2009-12-02 00:49    [W:0.021 / U:17.824 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site