03 Feb, 2011

1 commit

  • Make the tracepoints more robust, making them solid enough to handle compiler
    changes by not relying on anything based on compiler-specific behavior with
    respect to structure alignment. Implement an approach proposed by David Miller:
    use an array of const pointers to refer to the individual structures, and export
    this pointer array through the linker script rather than the structures per se.
    It will consume 32 extra bytes per tracepoint (24 for structure padding and 8
    for the pointers), but are less likely to break due to compiler changes.

    History:

    commit 7e066fb8 tracepoints: add DECLARE_TRACE() and DEFINE_TRACE()
    added the aligned(32) type and variable attribute to the tracepoint structures
    to deal with gcc happily aligning statically defined structures on 32-byte
    multiples.

    One attempt was to use a 8-byte alignment for tracepoint structures by applying
    both the variable and type attribute to tracepoint structures definitions and
    declarations. It worked fine with gcc 4.5.1, but broke with gcc 4.4.4 and 4.4.5.

    The reason is that the "aligned" attribute only specify the _minimum_ alignment
    for a structure, leaving both the compiler and the linker free to align on
    larger multiples. Because tracepoint.c expects the structures to be placed as an
    array within each section, up-alignment cause NULL-pointer exceptions due to the
    extra unexpected padding.

    (this patch applies on top of -tip)

    Signed-off-by: Mathieu Desnoyers
    Acked-by: David S. Miller
    LKML-Reference:
    CC: Frederic Weisbecker
    CC: Ingo Molnar
    CC: Thomas Gleixner
    CC: Andrew Morton
    CC: Peter Zijlstra
    CC: Rusty Russell
    Signed-off-by: Steven Rostedt

    Mathieu Desnoyers
     

08 Jan, 2011

2 commits


03 Dec, 2010

1 commit

  • There are instances in the kernel that we only want to trace
    a tracepoint when a certain condition is set. But we do not
    want to test for that condition in the core kernel.
    If we test for that condition before calling the tracepoin, then
    we will be performing that test even when tracing is not enabled.
    This is 99.99% of the time.

    We currently can just filter out on that condition, but that happens
    after we write to the trace buffer. We just wasted time writing to
    the ring buffer for an event we never cared about.

    This patch adds:

    TRACE_EVENT_CONDITION() and DEFINE_EVENT_CONDITION()

    These have a new TP_CONDITION() argument that comes right after
    the TP_ARGS(). This condition can use the parameters of TP_ARGS()
    in the TRACE_EVENT() to determine if the tracepoint should be traced
    or not. The TP_CONDITION() will be placed in a if (cond) trace;

    For example, for the tracepoint sched_wakeup, it is useless to
    trace a wakeup event where the caller never actually wakes
    anything up (where success == 0). So adding:

    TP_CONDITION(success),

    which uses the "success" parameter of the wakeup tracepoint
    will have it only trace when we have successfully woken up a
    task.

    Acked-by: Mathieu Desnoyers
    Acked-by: Frederic Weisbecker
    Cc: Arjan van de Ven
    Cc: Thomas Gleixner
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

18 Nov, 2010

1 commit

  • This introduces the new TRACE_EVENT_FLAGS() macro in order
    to set up initial event flags value.

    This macro must simply follow the definition of a trace event
    and take the event name and the flag value as parameters:

    TRACE_EVENT(my_event, .....
    ....
    );

    TRACE_EVENT_FLAGS(my_event, 1)

    This will set up 1 as the initial my_event->flags value.

    Signed-off-by: Frederic Weisbecker
    Cc: Ingo Molnar
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Thomas Gleixner
    Cc: Steven Rostedt
    Cc: Li Zefan
    Cc: Jason Baron

    Frederic Weisbecker
     

23 Sep, 2010

1 commit


22 Jun, 2010

1 commit


14 May, 2010

2 commits

  • This patch adds data to be passed to tracepoint callbacks.

    The created functions from DECLARE_TRACE() now need a mandatory data
    parameter. For example:

    DECLARE_TRACE(mytracepoint, int value, value)

    Will create the register function:

    int register_trace_mytracepoint((void(*)(void *data, int value))probe,
    void *data);

    As the first argument, all callbacks (probes) must take a (void *data)
    parameter. So a callback for the above tracepoint will look like:

    void myprobe(void *data, int value)
    {
    }

    The callback may choose to ignore the data parameter.

    This change allows callbacks to register a private data pointer along
    with the function probe.

    void mycallback(void *data, int value);

    register_trace_mytracepoint(mycallback, mydata);

    Then the mycallback() will receive the "mydata" as the first parameter
    before the args.

    A more detailed example:

    DECLARE_TRACE(mytracepoint, TP_PROTO(int status), TP_ARGS(status));

    /* In the C file */

    DEFINE_TRACE(mytracepoint, TP_PROTO(int status), TP_ARGS(status));

    [...]

    trace_mytracepoint(status);

    /* In a file registering this tracepoint */

    int my_callback(void *data, int status)
    {
    struct my_struct my_data = data;
    [...]
    }

    [...]
    my_data = kmalloc(sizeof(*my_data), GFP_KERNEL);
    init_my_data(my_data);
    register_trace_mytracepoint(my_callback, my_data);

    The same callback can also be registered to the same tracepoint as long
    as the data registered is different. Note, the data must also be used
    to unregister the callback:

    unregister_trace_mytracepoint(my_callback, my_data);

    Because of the data parameter, tracepoints declared this way can not have
    no args. That is:

    DECLARE_TRACE(mytracepoint, TP_PROTO(void), TP_ARGS());

    will cause an error.

    If no arguments are needed, a new macro can be used instead:

    DECLARE_TRACE_NOARGS(mytracepoint);

    Since there are no arguments, the proto and args fields are left out.

    This is part of a series to make the tracepoint footprint smaller:

    text data bss dec hex filename
    4913961 1088356 861512 6863829 68bbd5 vmlinux.orig
    4914025 1088868 861512 6864405 68be15 vmlinux.class
    4918492 1084612 861512 6864616 68bee8 vmlinux.tracepoint

    Again, this patch also increases the size of the kernel, but
    lays the ground work for decreasing it.

    v5: Fixed net/core/drop_monitor.c to handle these updates.

    v4: Moved the DECLARE_TRACE() DECLARE_TRACE_NOARGS out of the
    #ifdef CONFIG_TRACE_POINTS, since the two are the same in both
    cases. The __DECLARE_TRACE() is what changes.
    Thanks to Frederic Weisbecker for pointing this out.

    v3: Made all register_* functions require data to be passed and
    all callbacks to take a void * parameter as its first argument.
    This makes the calling functions comply with C standards.

    Also added more comments to the modifications of DECLARE_TRACE().

    v2: Made the DECLARE_TRACE() have the ability to pass arguments
    and added a new DECLARE_TRACE_NOARGS() for tracepoints that
    do not need any arguments.

    Acked-by: Mathieu Desnoyers
    Acked-by: Masami Hiramatsu
    Acked-by: Frederic Weisbecker
    Cc: Neil Horman
    Cc: David S. Miller
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     
  • This check is meant to be used by tracepoint users which do a direct cast of
    callbacks to (void *) for direct registration, thus bypassing the
    register_trace_##name and unregister_trace_##name checks.

    This permits to ensure that the callback type matches the function type at the
    call site, but without generating any code.

    Acked-by: Masami Hiramatsu
    Acked-by: Frederic Weisbecker
    Signed-off-by: Mathieu Desnoyers
    LKML-Reference:
    CC: Ingo Molnar
    CC: Andrew Morton
    CC: Thomas Gleixner
    CC: Peter Zijlstra
    CC: Arnaldo Carvalho de Melo
    CC: Lai Jiangshan
    CC: Li Zefan
    CC: Christoph Hellwig
    Signed-off-by: Steven Rostedt

    Mathieu Desnoyers
     

05 May, 2010

1 commit

  • When more than one header is included under CREATE_TRACE_POINTS
    the DECLARE_TRACE() macro is not defined back to its original meaning
    and the second include will fail to initialize the TRACE_EVENT()
    and DECLARE_TRACE() correctly.

    To fix this the tracepoint.h file moves the define of DECLARE_TRACE()
    out of the #ifdef _LINUX_TRACEPOINT_H protection (just like the
    define of the TRACE_EVENT()). This way the define_trace.h will undef
    the DECLARE_TRACE() at the end and allow new headers to start
    from scratch.

    This patch also requires fixing the include/events/napi.h

    It currently uses DECLARE_TRACE() and should be converted to a TRACE_EVENT()
    format. But I'll leave that change to the authors of that file.
    But since the napi.h file depends on using the CREATE_TRACE_POINTS
    and does not define its own DEFINE_TRACE() it must use the define_trace.h
    method instead.

    Cc: Neil Horman
    Cc: David S. Miller
    Cc: Mathieu Desnoyers
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

16 Mar, 2010

1 commit

  • tracepoint.h uses rcu_dereference(), which triggers this warning:

    [ 0.701161] ===================================================
    [ 0.702211] [ INFO: suspicious rcu_dereference_check() usage. ]
    [ 0.702716] ---------------------------------------------------
    [ 0.703203] include/trace/events/workqueue.h:68 invoked rcu_dereference_check() without protection!
    [ 0.703971] [ 0.703990] other info that might help us debug this:
    [ 0.703993]
    [ 0.705590]
    [ 0.705604] rcu_scheduler_active = 1, debug_locks = 0
    [ 0.706712] 1 lock held by swapper/1:
    [ 0.707229] #0: (cpu_add_remove_lock){+.+.+.}, at: [] cpu_maps_update_begin+0x14/0x20
    [ 0.710097]
    [ 0.710106] stack backtrace:
    [ 0.712602] Pid: 1, comm: swapper Not tainted 2.6.34-rc1-tip-01613-g72662bb #168
    [ 0.713231] Call Trace:
    [ 0.713997] [] lockdep_rcu_dereference+0x9d/0xb0
    [ 0.714746] [] create_workqueue_thread+0x107/0x110
    [ 0.715353] [] ? worker_thread+0x0/0x340
    [ 0.715845] [] __create_workqueue_key+0x138/0x240
    [ 0.716427] [] ? cpu_maps_update_done+0x12/0x20
    [ 0.717012] [] init_workqueues+0x6f/0x80
    [ 0.717530] [] kernel_init+0x102/0x1f0
    [ 0.717570] [] ? kernel_init+0x0/0x1f0
    [ 0.718944] [] kernel_thread_helper+0x6/0x10

    Signed-off-by: Lai Jiangshan
    Cc: Paul E. McKenney
    Cc: Mathieu Desnoyers
    Cc: Steven Rostedt
    Cc: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Lai Jiangshan
     

26 Nov, 2009

1 commit

  • It is not quite obvious at first sight what TRACE_EVENT_TEMPLATE
    does: does it define an event as well beyond defining a template?

    To clarify this, rename it to DECLARE_EVENT_CLASS, which follows
    the various 'DECLARE_*()' idioms we already have in the kernel:

    DECLARE_EVENT_CLASS(class)

    DEFINE_EVENT(class, event1)
    DEFINE_EVENT(class, event2)
    DEFINE_EVENT(class, event3)

    To complete this logic we should also rename TRACE_EVENT() to:

    DEFINE_SINGLE_EVENT(single_event)

    ... but in a more quiet moment of the kernel cycle.

    Cc: Pekka Enberg
    Cc: Steven Rostedt
    Cc: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

25 Nov, 2009

2 commits

  • After creating the TRACE_EVENT_TEMPLATE I started to look at other
    trace points to see what duplication was made. I noticed that there
    are several trace points where they are almost identical except for
    the name and the output format. Since TRACE_EVENT_TEMPLATE was successful
    in bringing down the size of trace events, I added a DEFINE_EVENT_PRINT.

    DEFINE_EVENT_PRINT is used just like DEFINE_EVENT is. That is, the
    DEFINE_EVENT_PRINT also uses a TRACE_EVENT_TEMPLATE, but it allows the
    developer to overwrite the print format. If there are two or more
    TRACE_EVENTS that are identical except for the name and print, then
    they can be converted to use a TRACE_EVENT_TEMPLATE. Since the
    TRACE_EVENT_TEMPLATE already does the print output, the first trace event
    would have its print format held in the TRACE_EVENT_TEMPLATE and
    be defined with a DEFINE_EVENT. The rest will use the DEFINE_EVENT_PRINT
    and override the print format.

    Converting the sched trace points to both DEFINE_EVENT and
    DEFINE_EVENT_PRINT. Five were converted to DEFINE_EVENT and two were
    converted to DEFINE_EVENT_PRINT.

    I was able to get the following:

    $ size kernel/sched.o-*
    text data bss dec hex filename
    79299 6776 2520 88595 15a13 kernel/sched.o-notrace
    101941 11896 2584 116421 1c6c5 kernel/sched.o-templ
    104779 11896 2584 119259 1d1db kernel/sched.o-trace

    sched.o-notrace is the scheduler compiled with no trace points.
    sched.o-templ is with the use of DEFINE_EVENT and DEFINE_EVENT_PRINT
    sched.o-trace is the current trace events.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     
  • There are some places in the kernel that define several tracepoints and
    they are all identical besides the name. The code to enable, disable and
    record is created for every trace point even if most of the code is
    identical.

    This patch adds TRACE_EVENT_TEMPLATE that lets the developer create
    a template TRACE_EVENT and create trace points with DEFINE_EVENT, which
    is based off of a given template. Each trace point used by this
    will share most of the code, and bring down the size of the kernel
    when there are several duplicate events.

    Usage is:

    TRACE_EVENT_TEMPLATE(name, proto, args, tstruct, assign, print);

    Which would be the same as defining a normal TRACE_EVENT.

    To create the trace events that the trace points will use:

    DEFINE_EVENT(template, name, proto, args) is done. The template
    is the name of the TRACE_EVENT_TEMPLATE to use. The name is the
    name of the trace point. The parameters proto and args must be the same
    as the proto and args of the template. If they are not the same,
    then a compile error will result. I tried hard removing this duplication
    but the C preprocessor is not powerful enough (or my CPP magic
    experience points is not at a high enough level) to not need them.

    A lot of trace events are coming in with new XFS development. Most of
    the trace points are identical except for the name. The following shows
    the advantage of having TRACE_EVENT_TEMPLATE:

    $ size fs/xfs/xfs.o.*
    text data bss dec hex filename
    452114 2788 3520 458422 6feb6 fs/xfs/xfs.o.old
    638482 38116 3744 680342 a6196 fs/xfs/xfs.o.template
    996954 38116 4480 1039550 fdcbe fs/xfs/xfs.o.trace

    xfs.o.old is without any tracepoints.
    xfs.o.template uses the new TRACE_EVENT_TEMPLATE.
    xfs.o.trace uses the current TRACE_EVENT macros.

    Requested-by: Christoph Hellwig
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

23 Sep, 2009

1 commit


26 Aug, 2009

4 commits

  • …deric/random-tracing into tracing/core

    Conflicts:
    include/linux/tracepoint.h

    Signed-off-by: Ingo Molnar <mingo@elte.hu>

    Ingo Molnar
     
  • The commit:
    commit 5ac35daa9343936038a3c9c4f4d6d3fe6a2a7bd8
    Author: Xiao Guangrong
    tracing/events: fix the include file dependencies

    Moved the TRACE_EVENT out of the ifdef protection of tracepoints.h
    but uses the define of TRACE_EVENT itself as protection. This patch
    adds comments to explain why.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     
  • The TRACE_EVENT depends on the include/linux/tracepoint.h first
    and include/trace/ftrace.h later, if we include the ftrace.h early,
    a building error will occur.

    Both define TRACE_EVENT in trace_a.h and trace_b.h, if we include
    those in .c file, like this:

    #define CREATE_TRACE_POINTS
    include
    include

    The above will not work, because the TRACE_EVENT was re-defined by
    the previous .h file.

    Reported-by: Wei Yongjun
    Signed-off-by: Xiao Guangrong
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Xiao Guangrong
     
  • It's not strictly correct for the tracepoint reg/unreg callbacks to
    occur when a client is hooking up, because the actual tracepoint may not
    be present yet. This happens to be fine for syscall, since that's in
    the core kernel, but it would cause problems for tracepoints defined in
    a module that hasn't been loaded yet. It also means the reg/unreg has
    to be EXPORTed for any modules to use the tracepoint (as in SystemTap).

    This patch removes DECLARE_TRACE_WITH_CALLBACK, and instead introduces
    DEFINE_TRACE_FN which stores the callbacks in struct tracepoint. The
    callbacks are used now when the active state of the tracepoint changes
    in set_tracepoint & disable_tracepoint.

    This also introduces TRACE_EVENT_FN, so ftrace events can also provide
    registration callbacks if needed.

    Signed-off-by: Josh Stone
    Cc: Jason Baron
    Cc: Frederic Weisbecker
    Cc: Ingo Molnar
    Cc: Li Zefan
    Cc: Steven Rostedt
    Cc: Peter Zijlstra
    Cc: Mathieu Desnoyers
    Cc: Jiaying Zhang
    Cc: Martin Bligh
    Cc: Lai Jiangshan
    Cc: Paul Mundt
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    LKML-Reference:
    Signed-off-by: Frederic Weisbecker

    Josh Stone
     

12 Aug, 2009

1 commit

  • Introduce a new 'DECLARE_TRACE_WITH_CALLBACK()' macro, so that
    tracepoints can associate an external register/unregister function.

    This prepares for the syscalls tracer conversion to trace events. We
    will need to perform arch level operations once a syscall event is
    turned on/off, such as TIF flags setting, hence the need of such
    specific callbacks.

    Signed-off-by: Jason Baron
    Cc: Lai Jiangshan
    Cc: Steven Rostedt
    Cc: Peter Zijlstra
    Cc: Mathieu Desnoyers
    Cc: Jiaying Zhang
    Cc: Martin Bligh
    Cc: Li Zefan
    Cc: Masami Hiramatsu
    Signed-off-by: Frederic Weisbecker

    Jason Baron
     

16 Jun, 2009

1 commit

  • Many developers use "/debug/" or "/debugfs/" or "/sys/kernel/debug/"
    directory name to mount debugfs filesystem for ftrace according to
    ./Documentation/tracers/ftrace.txt file.

    And, three directory names(ex:/debug/, /debugfs/, /sys/kernel/debug/) is
    existed in kernel source like ftrace, DRM, Wireless, Documentation,
    Network[sky2]files to mount debugfs filesystem.

    debugfs means debug filesystem for debugging easy to use by greg kroah
    hartman. "/sys/kernel/debug/" name is suitable as directory name
    of debugfs filesystem.
    - debugfs related reference: http://lwn.net/Articles/334546/

    Fix inconsistency of directory name to mount debugfs filesystem.

    * From Steven Rostedt
    - find_debugfs() and tracing_files() in this patch.

    Signed-off-by: GeunSik Lim
    Acked-by : Inaky Perez-Gonzalez
    Reviewed-by : Steven Rostedt
    Reviewed-by : James Smart
    CC: Jiri Kosina
    CC: David Airlie
    CC: Peter Osterlund
    CC: Ananth N Mavinakayanahalli
    CC: Anil S Keshavamurthy
    CC: Masami Hiramatsu
    Signed-off-by: Greg Kroah-Hartman

    GeunSik Lim
     

24 Apr, 2009

1 commit


14 Apr, 2009

1 commit

  • Impact: clean up

    Neil Horman (et. al.) criticized the way the trace events were broken up
    into two files. The reason for that was that ftrace needed to separate out
    the declarations from where the #include was used.
    It then dawned on me that the tracepoint.h header only needs to define the
    TRACE_EVENT macro if it is not already defined.

    The solution is simply to test if TRACE_EVENT is defined, and if it is not
    then the linux/tracepoint.h header can define it. This change consolidates
    all the .h and _event_types.h into the .h file.

    Reported-by: Neil Horman
    Reported-by: Theodore Tso
    Reported-by: Jiaying Zhang
    Cc: Zhaolei
    Cc: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Jason Baron
    Cc: Mathieu Desnoyers
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

11 Mar, 2009

3 commits


10 Mar, 2009

3 commits

  • Impact: clean up

    The TRACE_EVENT_FORMAT macro is no longer used by trace points
    and only the DECLARE_TRACE, TRACE_FORMAT or TRACE_EVENT macros should
    be used by them. Although the TRACE_EVENT_FORMAT macro is still used
    by the internal tracing utility, it should not be used in core
    kernel code.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     
  • Impact: clean up and enhancement

    The TRACE_EVENT_FORMAT macro looks quite ugly and is limited in its
    ability to save data as well as to print the record out. Working with
    Ingo Molnar, we came up with a new format that is much more pleasing to
    the eye of C developers. This new macro is more C style than the old
    macro, and is more obvious to what it does.

    Here's the example. The only updated macro in this patch is the
    sched_switch trace point.

    The old method looked like this:

    TRACE_EVENT_FORMAT(sched_switch,
    TP_PROTO(struct rq *rq, struct task_struct *prev,
    struct task_struct *next),
    TP_ARGS(rq, prev, next),
    TP_FMT("task %s:%d ==> %s:%d",
    prev->comm, prev->pid, next->comm, next->pid),
    TRACE_STRUCT(
    TRACE_FIELD(pid_t, prev_pid, prev->pid)
    TRACE_FIELD(int, prev_prio, prev->prio)
    TRACE_FIELD_SPECIAL(char next_comm[TASK_COMM_LEN],
    next_comm,
    TP_CMD(memcpy(TRACE_ENTRY->next_comm,
    next->comm,
    TASK_COMM_LEN)))
    TRACE_FIELD(pid_t, next_pid, next->pid)
    TRACE_FIELD(int, next_prio, next->prio)
    ),
    TP_RAW_FMT("prev %d:%d ==> next %s:%d:%d")
    );

    The above method is hard to read and requires two format fields.

    The new method:

    /*
    * Tracepoint for task switches, performed by the scheduler:
    *
    * (NOTE: the 'rq' argument is not used by generic trace events,
    * but used by the latency tracer plugin. )
    */
    TRACE_EVENT(sched_switch,

    TP_PROTO(struct rq *rq, struct task_struct *prev,
    struct task_struct *next),

    TP_ARGS(rq, prev, next),

    TP_STRUCT__entry(
    __array( char, prev_comm, TASK_COMM_LEN )
    __field( pid_t, prev_pid )
    __field( int, prev_prio )
    __array( char, next_comm, TASK_COMM_LEN )
    __field( pid_t, next_pid )
    __field( int, next_prio )
    ),

    TP_printk("task %s:%d [%d] ==> %s:%d [%d]",
    __entry->prev_comm, __entry->prev_pid, __entry->prev_prio,
    __entry->next_comm, __entry->next_pid, __entry->next_prio),

    TP_fast_assign(
    memcpy(__entry->next_comm, next->comm, TASK_COMM_LEN);
    __entry->prev_pid = prev->pid;
    __entry->prev_prio = prev->prio;
    memcpy(__entry->prev_comm, prev->comm, TASK_COMM_LEN);
    __entry->next_pid = next->pid;
    __entry->next_prio = next->prio;
    )
    );

    This macro is called TRACE_EVENT, it is broken up into 5 parts:

    TP_PROTO: the proto type of the trace point
    TP_ARGS: the arguments of the trace point
    TP_STRUCT_entry: the structure layout of the entry in the ring buffer
    TP_printk: the printk format
    TP_fast_assign: the method used to write the entry into the ring buffer

    The structure is the definition of how the event will be saved in the
    ring buffer. The printk is used by the internal tracing in case of
    an oops, and the kernel needs to print out the format of the record
    to the console. This the TP_printk gives a means to show the records
    in a human readable format. It is also used to print out the data
    from the trace file.

    The TP_fast_assign is executed directly. It is basically like a C function,
    where the __entry is the handle to the record.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     
  • Impact: clean up

    The macros TPPROTO, TPARGS, TPFMT, TPRAWFMT, and TPCMD all look a bit
    ugly. This patch adds an underscore to their names.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

28 Feb, 2009

1 commit


26 Feb, 2009

2 commits


25 Feb, 2009

1 commit

  • This patch creates a DEFINE_TRACE_FMT to map to DECLARE_TRACE.
    This allows for the developers to place format strings and
    args in with their tracepoint declaration. A tracer may now
    override the DEFINE_TRACE_FMT macro and use it to record
    a default format.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

16 Nov, 2008

4 commits


03 Nov, 2008

1 commit

  • Impact: add new tracepoint APIs to allow the batched registration of probes

    new APIs separate tracepoint_probe_register(),
    tracepoint_probe_unregister() into 2 steps. The first step of them
    is just update tracepoint_entry, not connect or disconnect.

    this patch introduces tracepoint_probe_update_all() for update all.

    these APIs are very useful for registering lots of probes
    but just updating once. Another very important thing is that
    *_noupdate APIs do not require module_mutex.

    Signed-off-by: Lai Jiangshan
    Acked-by: Mathieu Desnoyers
    Signed-off-by: Ingo Molnar

    Lai Jiangshan
     

14 Oct, 2008

2 commits