2012-04-06 02:47:52 +04:00
|
|
|
#ifndef _PERF_UTIL_TRACE_EVENT_H
|
|
|
|
|
#define _PERF_UTIL_TRACE_EVENT_H
|
2009-08-17 18:18:05 +04:00
|
|
|
|
2013-06-11 19:29:18 +04:00
|
|
|
#include <traceevent/event-parse.h>
|
2009-08-28 05:09:58 +04:00
|
|
|
#include "parse-events.h"
|
2011-11-28 13:56:39 +04:00
|
|
|
|
|
|
|
|
struct machine;
|
|
|
|
|
struct perf_sample;
|
|
|
|
|
union perf_event;
|
2012-06-27 20:08:42 +04:00
|
|
|
struct perf_tool;
|
2013-07-19 02:06:15 +04:00
|
|
|
struct thread;
|
2013-12-03 17:09:23 +04:00
|
|
|
struct plugin_list;
|
|
|
|
|
|
|
|
|
|
struct trace_event {
|
|
|
|
|
struct pevent *pevent;
|
|
|
|
|
struct plugin_list *plugin_list;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int trace_event__init(struct trace_event *t);
|
|
|
|
|
void trace_event__cleanup(struct trace_event *t);
|
perf python: Remove dependency on 'machine' methods
The python binding still doesn't provide symbol resolving facilities,
but the recent addition of the trace_event__register_resolver() function
made it add as a dependency the machine__resolve_kernel_addr() method,
that in turn drags all the symbol resolving code.
The problem:
[root@zoo ~]# perf test -v python
17: Try 'import perf' in python, checking link problems :
--- start ---
test child forked, pid 6853
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: /tmp/build/perf/python/perf.so: undefined symbol: machine__resolve_kernel_addr
test child finished with -1
---- end ----
Try 'import perf' in python, checking link problems: FAILED!
[root@zoo ~]#
Fix it by requiring this function to receive the resolver as a
parameter, just like pevent_register_function_resolver(), i.e. do
not explicitely refer to an object file not included in
tools/perf/util/python-ext-sources.
[root@zoo ~]# perf test python
17: Try 'import perf' in python, checking link problems : Ok
[root@zoo ~]#
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Fixes: c3168b0db93a ("perf symbols: Provide libtraceevent callback to resolve kernel symbols")
Link: http://lkml.kernel.org/n/tip-vxlhh95v2em9zdbgj3jm7xi5@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2015-07-24 18:13:05 +03:00
|
|
|
int trace_event__register_resolver(struct machine *machine,
|
|
|
|
|
pevent_func_resolver_t *func);
|
2013-12-03 17:09:24 +04:00
|
|
|
struct event_format*
|
|
|
|
|
trace_event__tp_format(const char *sys, const char *name);
|
2009-08-17 18:18:05 +04:00
|
|
|
|
2012-04-06 02:47:56 +04:00
|
|
|
int bigendian(void);
|
|
|
|
|
|
2015-02-03 18:46:58 +03:00
|
|
|
void event_format__fprintf(struct event_format *event,
|
|
|
|
|
int cpu, void *data, int size, FILE *fp);
|
|
|
|
|
|
2012-08-07 16:58:03 +04:00
|
|
|
void event_format__print(struct event_format *event,
|
|
|
|
|
int cpu, void *data, int size);
|
2012-04-06 02:47:56 +04:00
|
|
|
|
2012-06-27 20:08:42 +04:00
|
|
|
int parse_ftrace_file(struct pevent *pevent, char *buf, unsigned long size);
|
|
|
|
|
int parse_event_file(struct pevent *pevent,
|
|
|
|
|
char *buf, unsigned long size, char *sys);
|
2012-04-06 02:47:56 +04:00
|
|
|
|
|
|
|
|
unsigned long long
|
|
|
|
|
raw_field_value(struct event_format *event, const char *name, void *data);
|
|
|
|
|
|
2012-06-27 20:08:42 +04:00
|
|
|
void parse_proc_kallsyms(struct pevent *pevent, char *file, unsigned int size);
|
|
|
|
|
void parse_ftrace_printk(struct pevent *pevent, char *file, unsigned int size);
|
2012-04-06 02:47:56 +04:00
|
|
|
|
2013-12-03 17:09:23 +04:00
|
|
|
ssize_t trace_report(int fd, struct trace_event *tevent, bool repipe);
|
2012-04-06 02:47:56 +04:00
|
|
|
|
2012-06-27 20:08:42 +04:00
|
|
|
struct event_format *trace_find_next_event(struct pevent *pevent,
|
|
|
|
|
struct event_format *event);
|
2012-08-08 06:50:21 +04:00
|
|
|
unsigned long long read_size(struct event_format *event, void *ptr, int size);
|
2012-04-06 02:47:56 +04:00
|
|
|
unsigned long long eval_flag(const char *flag);
|
|
|
|
|
|
2011-01-03 21:39:04 +03:00
|
|
|
int read_tracing_data(int fd, struct list_head *pattrs);
|
2011-10-20 17:59:43 +04:00
|
|
|
|
|
|
|
|
struct tracing_data {
|
|
|
|
|
/* size is only valid if temp is 'true' */
|
|
|
|
|
ssize_t size;
|
|
|
|
|
bool temp;
|
|
|
|
|
char temp_file[50];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct tracing_data *tracing_data_get(struct list_head *pattrs,
|
|
|
|
|
int fd, bool temp);
|
2013-03-21 11:18:46 +04:00
|
|
|
int tracing_data_put(struct tracing_data *tdata);
|
2011-10-20 17:59:43 +04:00
|
|
|
|
2009-08-17 18:18:05 +04:00
|
|
|
|
2012-08-08 13:57:52 +04:00
|
|
|
struct addr_location;
|
|
|
|
|
|
2012-08-07 17:20:46 +04:00
|
|
|
struct perf_session;
|
2016-01-06 00:09:08 +03:00
|
|
|
struct perf_stat_config;
|
2012-08-07 17:20:46 +04:00
|
|
|
|
perf trace: Add scripting ops
Adds an interface, scripting_ops, that when implemented for a
particular scripting language enables built-in support for trace
stream processing using that language.
The interface is designed to enable full-fledged language
interpreters to be embedded inside the perf executable and
thereby make the full capabilities of the supported languages
available for trace processing.
See below for details on the interface.
This patch also adds a couple command-line options to 'perf
trace':
The -s option option is used to specify the script to be run.
Script names that can be used with -s take the form:
[language spec:]scriptname[.ext]
Scripting languages register a set of 'language specs' that can
be used to specify scripts for the registered languages. The
specs can be used either as prefixes or extensions.
If [language spec:] is used, the script is taken as a script of
the matching language regardless of any extension it might have.
If [language spec:] is not used, [.ext] is used to look up the
language it corresponds to. Language specs are case
insensitive.
e.g. Perl scripts can be specified in the following ways:
Perl:scriptname
pl:scriptname.py # extension ignored
PL:scriptname
scriptname.pl
scriptname.perl
The -g [language spec] option gives users an easy starting point
for writing scripts in the specified language. Scripting
support for a particular language can implement a
generate_script() scripting op that outputs an empty (or
near-empty) set of handlers for all the events contained in a
given perf.data trace file - this option gives users a direct
way to access that.
Adding support for a scripting language
---------------------------------------
The main thing that needs to be done do add support for a new
language is to implement the scripting_ops interface:
It consists of the following four functions:
start_script()
stop_script()
process_event()
generate_script()
start_script() is called before any events are processed, and is
meant to give the scripting language support an opportunity to
set things up to receive events e.g. create and initialize an
instance of a language interpreter.
stop_script() is called after all events are processed, and is
meant to give the scripting language support an opportunity to
clean up e.g. destroy the interpreter instance, etc.
process_event() is called once for each event and takes as its
main parameter a pointer to the binary trace event record to be
processed. The implementation is responsible for picking out the
binary fields from the event record and sending them to the
script handler function associated with that event e.g. a
function derived from the event name it's meant to handle e.g.
'sched::sched_switch()'. The 'format' information for trace
events can be used to parse the binary data and map it into a
form usable by a given scripting language; see the Perl
implemention in subsequent patches for one possible way to
leverage the existing trace format parsing code in perf and map
that info into specific scripting language types.
generate_script() should generate a ready-to-run script for the
current set of events in the trace, preferably with bodies that
print out every field for each event. Again, look at the Perl
implementation for clues as to how that can be done. This is an
optional, but very useful op.
Support for a given language should also add a language-specific
setup function and call it from setup_scripting(). The
language-specific setup function associates the the scripting
ops for that language with one or more 'language specifiers'
(see below) using script_spec_register(). When a script name is
specified on the command line, the scripting ops associated with
the specified language are used to instantiate and use the
appropriate interpreter to process the trace stream.
In general, it should be relatively easy to add support for a
new language, especially if the language implementation supports
an interface allowing an interpreter to be 'embedded' inside
another program (in this case the containing program will be
'perf trace'). If so, it should be relatively straightforward to
translate trace events into invocations of user-defined script
functions where e.g. the function name corresponds to the event
type and the function parameters correspond to the event fields.
The event and field type information exported by the event
tracing infrastructure (via the event 'format' files) should be
enough to parse and send any piece of trace data to the user
script. The easiest way to see how this can be done would be to
look at the Perl implementation contained in
perf/util/trace-event-perl.c/.h.
There are a couple of other things that aren't covered by the
scripting_ops or setup interface and are technically optional,
but should be implemented if possible. One of these is support
for 'flag' and 'symbolic' fields e.g. being able to use more
human-readable values such as 'GFP_KERNEL' or
HI/BLOCK_IOPOLL/TASKLET in place of raw flag values. See the
Perl implementation to see how this can be done. The other thing
is support for 'calling back' into the perf executable to access
e.g. uncommon fields not passed by default into handler
functions, or any metadata the implementation might want to make
available to users via the language interface. Again, see the
Perl implementation for examples.
Signed-off-by: Tom Zanussi <tzanussi@gmail.com>
Cc: fweisbec@gmail.com
Cc: rostedt@goodmis.org
Cc: anton@samba.org
Cc: hch@infradead.org
LKML-Reference: <1259133352-23685-2-git-send-email-tzanussi@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-25 10:15:46 +03:00
|
|
|
struct scripting_ops {
|
|
|
|
|
const char *name;
|
2009-12-15 11:53:35 +03:00
|
|
|
int (*start_script) (const char *script, int argc, const char **argv);
|
2014-08-15 23:08:37 +04:00
|
|
|
int (*flush_script) (void);
|
perf trace: Add scripting ops
Adds an interface, scripting_ops, that when implemented for a
particular scripting language enables built-in support for trace
stream processing using that language.
The interface is designed to enable full-fledged language
interpreters to be embedded inside the perf executable and
thereby make the full capabilities of the supported languages
available for trace processing.
See below for details on the interface.
This patch also adds a couple command-line options to 'perf
trace':
The -s option option is used to specify the script to be run.
Script names that can be used with -s take the form:
[language spec:]scriptname[.ext]
Scripting languages register a set of 'language specs' that can
be used to specify scripts for the registered languages. The
specs can be used either as prefixes or extensions.
If [language spec:] is used, the script is taken as a script of
the matching language regardless of any extension it might have.
If [language spec:] is not used, [.ext] is used to look up the
language it corresponds to. Language specs are case
insensitive.
e.g. Perl scripts can be specified in the following ways:
Perl:scriptname
pl:scriptname.py # extension ignored
PL:scriptname
scriptname.pl
scriptname.perl
The -g [language spec] option gives users an easy starting point
for writing scripts in the specified language. Scripting
support for a particular language can implement a
generate_script() scripting op that outputs an empty (or
near-empty) set of handlers for all the events contained in a
given perf.data trace file - this option gives users a direct
way to access that.
Adding support for a scripting language
---------------------------------------
The main thing that needs to be done do add support for a new
language is to implement the scripting_ops interface:
It consists of the following four functions:
start_script()
stop_script()
process_event()
generate_script()
start_script() is called before any events are processed, and is
meant to give the scripting language support an opportunity to
set things up to receive events e.g. create and initialize an
instance of a language interpreter.
stop_script() is called after all events are processed, and is
meant to give the scripting language support an opportunity to
clean up e.g. destroy the interpreter instance, etc.
process_event() is called once for each event and takes as its
main parameter a pointer to the binary trace event record to be
processed. The implementation is responsible for picking out the
binary fields from the event record and sending them to the
script handler function associated with that event e.g. a
function derived from the event name it's meant to handle e.g.
'sched::sched_switch()'. The 'format' information for trace
events can be used to parse the binary data and map it into a
form usable by a given scripting language; see the Perl
implemention in subsequent patches for one possible way to
leverage the existing trace format parsing code in perf and map
that info into specific scripting language types.
generate_script() should generate a ready-to-run script for the
current set of events in the trace, preferably with bodies that
print out every field for each event. Again, look at the Perl
implementation for clues as to how that can be done. This is an
optional, but very useful op.
Support for a given language should also add a language-specific
setup function and call it from setup_scripting(). The
language-specific setup function associates the the scripting
ops for that language with one or more 'language specifiers'
(see below) using script_spec_register(). When a script name is
specified on the command line, the scripting ops associated with
the specified language are used to instantiate and use the
appropriate interpreter to process the trace stream.
In general, it should be relatively easy to add support for a
new language, especially if the language implementation supports
an interface allowing an interpreter to be 'embedded' inside
another program (in this case the containing program will be
'perf trace'). If so, it should be relatively straightforward to
translate trace events into invocations of user-defined script
functions where e.g. the function name corresponds to the event
type and the function parameters correspond to the event fields.
The event and field type information exported by the event
tracing infrastructure (via the event 'format' files) should be
enough to parse and send any piece of trace data to the user
script. The easiest way to see how this can be done would be to
look at the Perl implementation contained in
perf/util/trace-event-perl.c/.h.
There are a couple of other things that aren't covered by the
scripting_ops or setup interface and are technically optional,
but should be implemented if possible. One of these is support
for 'flag' and 'symbolic' fields e.g. being able to use more
human-readable values such as 'GFP_KERNEL' or
HI/BLOCK_IOPOLL/TASKLET in place of raw flag values. See the
Perl implementation to see how this can be done. The other thing
is support for 'calling back' into the perf executable to access
e.g. uncommon fields not passed by default into handler
functions, or any metadata the implementation might want to make
available to users via the language interface. Again, see the
Perl implementation for examples.
Signed-off-by: Tom Zanussi <tzanussi@gmail.com>
Cc: fweisbec@gmail.com
Cc: rostedt@goodmis.org
Cc: anton@samba.org
Cc: hch@infradead.org
LKML-Reference: <1259133352-23685-2-git-send-email-tzanussi@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-25 10:15:46 +03:00
|
|
|
int (*stop_script) (void);
|
2011-03-10 08:23:23 +03:00
|
|
|
void (*process_event) (union perf_event *event,
|
|
|
|
|
struct perf_sample *sample,
|
2011-03-15 21:44:01 +03:00
|
|
|
struct perf_evsel *evsel,
|
2015-04-01 19:29:25 +03:00
|
|
|
struct addr_location *al);
|
2016-01-06 00:09:08 +03:00
|
|
|
void (*process_stat)(struct perf_stat_config *config,
|
|
|
|
|
struct perf_evsel *evsel, u64 tstamp);
|
|
|
|
|
void (*process_stat_interval)(u64 tstamp);
|
2012-06-27 20:08:42 +04:00
|
|
|
int (*generate_script) (struct pevent *pevent, const char *outfile);
|
perf trace: Add scripting ops
Adds an interface, scripting_ops, that when implemented for a
particular scripting language enables built-in support for trace
stream processing using that language.
The interface is designed to enable full-fledged language
interpreters to be embedded inside the perf executable and
thereby make the full capabilities of the supported languages
available for trace processing.
See below for details on the interface.
This patch also adds a couple command-line options to 'perf
trace':
The -s option option is used to specify the script to be run.
Script names that can be used with -s take the form:
[language spec:]scriptname[.ext]
Scripting languages register a set of 'language specs' that can
be used to specify scripts for the registered languages. The
specs can be used either as prefixes or extensions.
If [language spec:] is used, the script is taken as a script of
the matching language regardless of any extension it might have.
If [language spec:] is not used, [.ext] is used to look up the
language it corresponds to. Language specs are case
insensitive.
e.g. Perl scripts can be specified in the following ways:
Perl:scriptname
pl:scriptname.py # extension ignored
PL:scriptname
scriptname.pl
scriptname.perl
The -g [language spec] option gives users an easy starting point
for writing scripts in the specified language. Scripting
support for a particular language can implement a
generate_script() scripting op that outputs an empty (or
near-empty) set of handlers for all the events contained in a
given perf.data trace file - this option gives users a direct
way to access that.
Adding support for a scripting language
---------------------------------------
The main thing that needs to be done do add support for a new
language is to implement the scripting_ops interface:
It consists of the following four functions:
start_script()
stop_script()
process_event()
generate_script()
start_script() is called before any events are processed, and is
meant to give the scripting language support an opportunity to
set things up to receive events e.g. create and initialize an
instance of a language interpreter.
stop_script() is called after all events are processed, and is
meant to give the scripting language support an opportunity to
clean up e.g. destroy the interpreter instance, etc.
process_event() is called once for each event and takes as its
main parameter a pointer to the binary trace event record to be
processed. The implementation is responsible for picking out the
binary fields from the event record and sending them to the
script handler function associated with that event e.g. a
function derived from the event name it's meant to handle e.g.
'sched::sched_switch()'. The 'format' information for trace
events can be used to parse the binary data and map it into a
form usable by a given scripting language; see the Perl
implemention in subsequent patches for one possible way to
leverage the existing trace format parsing code in perf and map
that info into specific scripting language types.
generate_script() should generate a ready-to-run script for the
current set of events in the trace, preferably with bodies that
print out every field for each event. Again, look at the Perl
implementation for clues as to how that can be done. This is an
optional, but very useful op.
Support for a given language should also add a language-specific
setup function and call it from setup_scripting(). The
language-specific setup function associates the the scripting
ops for that language with one or more 'language specifiers'
(see below) using script_spec_register(). When a script name is
specified on the command line, the scripting ops associated with
the specified language are used to instantiate and use the
appropriate interpreter to process the trace stream.
In general, it should be relatively easy to add support for a
new language, especially if the language implementation supports
an interface allowing an interpreter to be 'embedded' inside
another program (in this case the containing program will be
'perf trace'). If so, it should be relatively straightforward to
translate trace events into invocations of user-defined script
functions where e.g. the function name corresponds to the event
type and the function parameters correspond to the event fields.
The event and field type information exported by the event
tracing infrastructure (via the event 'format' files) should be
enough to parse and send any piece of trace data to the user
script. The easiest way to see how this can be done would be to
look at the Perl implementation contained in
perf/util/trace-event-perl.c/.h.
There are a couple of other things that aren't covered by the
scripting_ops or setup interface and are technically optional,
but should be implemented if possible. One of these is support
for 'flag' and 'symbolic' fields e.g. being able to use more
human-readable values such as 'GFP_KERNEL' or
HI/BLOCK_IOPOLL/TASKLET in place of raw flag values. See the
Perl implementation to see how this can be done. The other thing
is support for 'calling back' into the perf executable to access
e.g. uncommon fields not passed by default into handler
functions, or any metadata the implementation might want to make
available to users via the language interface. Again, see the
Perl implementation for examples.
Signed-off-by: Tom Zanussi <tzanussi@gmail.com>
Cc: fweisbec@gmail.com
Cc: rostedt@goodmis.org
Cc: anton@samba.org
Cc: hch@infradead.org
LKML-Reference: <1259133352-23685-2-git-send-email-tzanussi@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-25 10:15:46 +03:00
|
|
|
};
|
|
|
|
|
|
2015-09-25 16:15:50 +03:00
|
|
|
extern unsigned int scripting_max_stack;
|
|
|
|
|
|
perf trace: Add scripting ops
Adds an interface, scripting_ops, that when implemented for a
particular scripting language enables built-in support for trace
stream processing using that language.
The interface is designed to enable full-fledged language
interpreters to be embedded inside the perf executable and
thereby make the full capabilities of the supported languages
available for trace processing.
See below for details on the interface.
This patch also adds a couple command-line options to 'perf
trace':
The -s option option is used to specify the script to be run.
Script names that can be used with -s take the form:
[language spec:]scriptname[.ext]
Scripting languages register a set of 'language specs' that can
be used to specify scripts for the registered languages. The
specs can be used either as prefixes or extensions.
If [language spec:] is used, the script is taken as a script of
the matching language regardless of any extension it might have.
If [language spec:] is not used, [.ext] is used to look up the
language it corresponds to. Language specs are case
insensitive.
e.g. Perl scripts can be specified in the following ways:
Perl:scriptname
pl:scriptname.py # extension ignored
PL:scriptname
scriptname.pl
scriptname.perl
The -g [language spec] option gives users an easy starting point
for writing scripts in the specified language. Scripting
support for a particular language can implement a
generate_script() scripting op that outputs an empty (or
near-empty) set of handlers for all the events contained in a
given perf.data trace file - this option gives users a direct
way to access that.
Adding support for a scripting language
---------------------------------------
The main thing that needs to be done do add support for a new
language is to implement the scripting_ops interface:
It consists of the following four functions:
start_script()
stop_script()
process_event()
generate_script()
start_script() is called before any events are processed, and is
meant to give the scripting language support an opportunity to
set things up to receive events e.g. create and initialize an
instance of a language interpreter.
stop_script() is called after all events are processed, and is
meant to give the scripting language support an opportunity to
clean up e.g. destroy the interpreter instance, etc.
process_event() is called once for each event and takes as its
main parameter a pointer to the binary trace event record to be
processed. The implementation is responsible for picking out the
binary fields from the event record and sending them to the
script handler function associated with that event e.g. a
function derived from the event name it's meant to handle e.g.
'sched::sched_switch()'. The 'format' information for trace
events can be used to parse the binary data and map it into a
form usable by a given scripting language; see the Perl
implemention in subsequent patches for one possible way to
leverage the existing trace format parsing code in perf and map
that info into specific scripting language types.
generate_script() should generate a ready-to-run script for the
current set of events in the trace, preferably with bodies that
print out every field for each event. Again, look at the Perl
implementation for clues as to how that can be done. This is an
optional, but very useful op.
Support for a given language should also add a language-specific
setup function and call it from setup_scripting(). The
language-specific setup function associates the the scripting
ops for that language with one or more 'language specifiers'
(see below) using script_spec_register(). When a script name is
specified on the command line, the scripting ops associated with
the specified language are used to instantiate and use the
appropriate interpreter to process the trace stream.
In general, it should be relatively easy to add support for a
new language, especially if the language implementation supports
an interface allowing an interpreter to be 'embedded' inside
another program (in this case the containing program will be
'perf trace'). If so, it should be relatively straightforward to
translate trace events into invocations of user-defined script
functions where e.g. the function name corresponds to the event
type and the function parameters correspond to the event fields.
The event and field type information exported by the event
tracing infrastructure (via the event 'format' files) should be
enough to parse and send any piece of trace data to the user
script. The easiest way to see how this can be done would be to
look at the Perl implementation contained in
perf/util/trace-event-perl.c/.h.
There are a couple of other things that aren't covered by the
scripting_ops or setup interface and are technically optional,
but should be implemented if possible. One of these is support
for 'flag' and 'symbolic' fields e.g. being able to use more
human-readable values such as 'GFP_KERNEL' or
HI/BLOCK_IOPOLL/TASKLET in place of raw flag values. See the
Perl implementation to see how this can be done. The other thing
is support for 'calling back' into the perf executable to access
e.g. uncommon fields not passed by default into handler
functions, or any metadata the implementation might want to make
available to users via the language interface. Again, see the
Perl implementation for examples.
Signed-off-by: Tom Zanussi <tzanussi@gmail.com>
Cc: fweisbec@gmail.com
Cc: rostedt@goodmis.org
Cc: anton@samba.org
Cc: hch@infradead.org
LKML-Reference: <1259133352-23685-2-git-send-email-tzanussi@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-25 10:15:46 +03:00
|
|
|
int script_spec_register(const char *spec, struct scripting_ops *ops);
|
|
|
|
|
|
2009-11-25 10:15:48 +03:00
|
|
|
void setup_perl_scripting(void);
|
2010-01-27 11:27:57 +03:00
|
|
|
void setup_python_scripting(void);
|
2009-11-25 10:15:48 +03:00
|
|
|
|
2010-01-27 11:27:54 +03:00
|
|
|
struct scripting_context {
|
2012-06-27 20:08:42 +04:00
|
|
|
struct pevent *pevent;
|
2010-01-27 11:27:54 +03:00
|
|
|
void *event_data;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int common_pc(struct scripting_context *context);
|
|
|
|
|
int common_flags(struct scripting_context *context);
|
|
|
|
|
int common_lock_depth(struct scripting_context *context);
|
|
|
|
|
|
2012-04-06 02:47:52 +04:00
|
|
|
#endif /* _PERF_UTIL_TRACE_EVENT_H */
|
