lkml.org 
[lkml]   [2010]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes
    On Mon, Jan 11, 2010 at 05:56:08PM +0530, Srikar Dronamraju wrote:
    > This patch implements ftrace plugin for uprobes.
    >
    > Description:
    > Ftrace plugin provides an interface to dump data at a given address, top of
    > the stack and function arguments when a user program calls a specific
    > function.


    So, as told before, ftrace plugins tend to be relegated to
    obsolescence and I first suggested to plug this into kprobe
    events so that we have a unified interface to control/create
    u|k|kret probe events.

    But after digging more into first appearances, uprobe creation
    can follow the kprobes creation flow.

    kprobe can be created whenever we want. This is about probing
    kernel text and it is already there so that we can set the
    probe, default deactivated, in advance.

    This is much more tricky in the case of uprobes as I see two
    ways to work with it:

    - probing on an already running process
    - probing on a process we are about to run

    Now say we create to create a uprobe trace event for an already
    running process. No problem in the workflow, we just need to
    set the address and the pid. Fine.

    Now what if I want to launch ls and want to profile a function
    inside. What can I do with a trace event. I can't create the
    probe event based on a pid as I don't know it in advance.
    I could give it the ls cmdline and it manages to activate
    on the next ls launched. This is racy as another ls can
    be launched concurrently.

    So I can only say there that an ftrace plugin or an ftrace trace
    event would be only a half-useful interface to exploit utrace
    possibilities because it only lets us trace already running
    apps. Moreover I bet the most chosen workflow to profile/trace
    uprobes is by launching an app and profile it from the beginning,
    not by profiling an already running one, which makes an ftrace
    interface even less than half useful there.

    ftrace is cool to trace the kernel, but this kind of tricky
    userspace tracing workflow is not adapted to it.

    What do you think?



    \
     
     \ /
      Last update: 2010-01-12 05:57    [W:0.022 / U:95.316 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site