lkml.org 
[lkml]   [2006]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
    Roman Zippel wrote:
    > Hi,
    >
    > On Mon, 18 Sep 2006, Nick Piggin wrote:
    >
    >
    >>Above, weren't you asking about static vs dynamic trace-*points*, rather
    >>than the implementation of the tracer itself. I think Ingo said that
    >>some "static tracepoints" (eg. annotation) could be acceptable.
    >
    >
    > No, he made it rather clear, that as far as possible he only wants dynamic
    > annotations (e.g. via function attributes).

    OK we must have him interpreted differently. I won't speak for Ingo,
    but he can respond if he likes.

    >>Now it seems you are talking about compiled vs runtime inserted traces,
    >>which is different. And so far I have to agree with Ingo: dynamic seems
    >>to be better in almost every way. Implementation may be more complex,
    >>but that's never stood in the way of a better solution before, and I
    >>don't think anybody has shown it to be prohibitive ("I won't implement
    >>it" notwithstanding)
    >
    >
    > I don't deny that dynamic tracer are more flexible, but I simply don't
    > have the resources to implement one. If those who demand I use a dynamic
    > tracer, would also provide the appropriate funding, it would change the
    > situation completely, but without that I have to live with the tools
    > available to me.

    You definitely don't have to use a dynamic tracer, nor even implement
    one on m68k (that will presumably happen if/when somebody does want a
    dynamic tracer enough).

    But equally nobody can demand that a feature go into the upstream
    kernel. Especially not if there is a more flexible alternative
    already available that just requires implementing for their arch.

    This shouldn't be surprising, the kernel doesn't have a doctrine of
    unlimited choice or merge features because they exist. For example
    people wanted pluggable (runtime and/or compile time CPU scheduler
    in the kernel. This was rejected (IIRC by Linus, Andrew, Ingo, and
    myself). No doubt it would have been useful for a small number of
    people but it was decided that it would split testing and development
    resources. The STREAMS example is another one.

    As an aside, there are quite a number of different types of tracing
    things (mostly static, compile out) in the kernel. Everything from
    blktrace to various userspace notifiers to lots of /proc/stuff could
    be considered a type of static event tracing. I don't know what my
    point is other than all these big, disjoint frameworks trying to be
    pushed into the kernel. Are there any plans for working some things
    together, or is that somebody else's problem?

    Nick

    --
    SUSE Labs, Novell Inc.
    Send instant messages to your online friends http://au.messenger.yahoo.com

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

    \
     
     \ /
      Last update: 2006-09-17 19:59    [W:3.683 / U:0.484 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site