)]}'
{
  "commit": "956ffd027bedc4106b901eb6a50f0a6c6de4113d",
  "tree": "11634edc2ac27a81db9a5d2a15b3897992761272",
  "parents": [
    "1ed091c45ae33b2179d387573c3fe3f3b4adf60a"
  ],
  "author": {
    "name": "Tom Zanussi",
    "email": "tzanussi@gmail.com",
    "time": "Wed Nov 25 01:15:46 2009 -0600"
  },
  "committer": {
    "name": "Ingo Molnar",
    "email": "mingo@elte.hu",
    "time": "Sat Nov 28 10:04:24 2009 +0100"
  },
  "message": "perf trace: Add scripting ops\n\nAdds an interface, scripting_ops, that when implemented for a\nparticular scripting language enables built-in support for trace\nstream processing using that language.\n\nThe interface is designed to enable full-fledged language\ninterpreters to be embedded inside the perf executable and\nthereby make the full capabilities of the supported languages\navailable for trace processing.\n\nSee below for details on the interface.\n\nThis patch also adds a couple command-line options to \u0027perf\ntrace\u0027:\n\nThe -s option option is used to specify the script to be run.\nScript names that can be used with -s take the form:\n\n[language spec:]scriptname[.ext]\n\nScripting languages register a set of \u0027language specs\u0027 that can\nbe used to specify scripts for the registered languages.  The\nspecs can be used either as prefixes or extensions.\n\nIf [language spec:] is used, the script is taken as a script of\nthe matching language regardless of any extension it might have.\n If [language spec:] is not used, [.ext] is used to look up the\nlanguage it corresponds to.  Language specs are case\ninsensitive.\n\ne.g. Perl scripts can be specified in the following ways:\n\nPerl:scriptname\npl:scriptname.py # extension ignored\nPL:scriptname\nscriptname.pl\nscriptname.perl\n\nThe -g [language spec] option gives users an easy starting point\nfor writing scripts in the specified language.  Scripting\nsupport for a particular language can implement a\ngenerate_script() scripting op that outputs an empty (or\nnear-empty) set of handlers for all the events contained in a\ngiven perf.data trace file - this option gives users a direct\nway to access that.\n\nAdding support for a scripting language\n---------------------------------------\n\nThe main thing that needs to be done do add support for a new\nlanguage is to implement the scripting_ops interface:\n\nIt consists of the following four functions:\n\n    start_script()\n    stop_script()\n    process_event()\n    generate_script()\n\nstart_script() is called before any events are processed, and is\nmeant to give the scripting language support an opportunity to\nset things up to receive events e.g. create and initialize an\ninstance of a language interpreter.\n\nstop_script() is called after all events are processed, and is\nmeant to give the scripting language support an opportunity to\nclean up e.g. destroy the interpreter instance, etc.\n\nprocess_event() is called once for each event and takes as its\nmain parameter a pointer to the binary trace event record to be\nprocessed. The implementation is responsible for picking out the\nbinary fields from the event record and sending them to the\nscript handler function associated with that event e.g. a\nfunction derived from the event name it\u0027s meant to handle e.g.\n\u0027sched::sched_switch()\u0027.  The \u0027format\u0027 information for trace\nevents can be used to parse the binary data and map it into a\nform usable by a given scripting language; see the Perl\nimplemention in subsequent patches for one possible way to\nleverage the existing trace format parsing code in perf and map\nthat info into specific scripting language types.\n\ngenerate_script() should generate a ready-to-run script for the\ncurrent set of events in the trace, preferably with bodies that\nprint out every field for each event.  Again, look at the Perl\nimplementation for clues as to how that can be done.  This is an\noptional, but very useful op.\n\nSupport for a given language should also add a language-specific\nsetup function and call it from setup_scripting().  The\nlanguage-specific setup function associates the the scripting\nops for that language with one or more \u0027language specifiers\u0027\n(see below) using script_spec_register().  When a script name is\nspecified on the command line, the scripting ops associated with\nthe specified language are used to instantiate and use the\nappropriate interpreter to process the trace stream.\n\nIn general, it should be relatively easy to add support for a\nnew language, especially if the language implementation supports\nan interface allowing an interpreter to be \u0027embedded\u0027 inside\nanother program (in this case the containing program will be\n\u0027perf trace\u0027). If so, it should be relatively straightforward to\ntranslate trace events into invocations of user-defined script\nfunctions where e.g. the function name corresponds to the event\ntype and the function parameters correspond to the event fields.\n The event and field type information exported by the event\ntracing infrastructure (via the event \u0027format\u0027 files) should be\nenough to parse and send any piece of trace data to the user\nscript.  The easiest way to see how this can be done would be to\nlook at the Perl implementation contained in\nperf/util/trace-event-perl.c/.h.\n\nThere are a couple of other things that aren\u0027t covered by the\nscripting_ops or setup interface and are technically optional,\nbut should be implemented if possible.  One of these is support\nfor \u0027flag\u0027 and \u0027symbolic\u0027 fields e.g. being able to use more\nhuman-readable values such as \u0027GFP_KERNEL\u0027 or\nHI/BLOCK_IOPOLL/TASKLET in place of raw flag values.  See the\nPerl implementation to see how this can be done. The other thing\nis support for \u0027calling back\u0027 into the perf executable to access\ne.g. uncommon fields not passed by default into handler\nfunctions, or any metadata the implementation might want to make\navailable to users via the language interface.  Again, see the\nPerl implementation for examples.\n\nSigned-off-by: Tom Zanussi \u003ctzanussi@gmail.com\u003e\nCc: fweisbec@gmail.com\nCc: rostedt@goodmis.org\nCc: anton@samba.org\nCc: hch@infradead.org\nLKML-Reference: \u003c1259133352-23685-2-git-send-email-tzanussi@gmail.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "a7750256c408d6e014da475a8bc9eb5507a1bfba",
      "old_mode": 33188,
      "old_path": "tools/perf/builtin-trace.c",
      "new_id": "e96bb534b9489d86ed0cf12ba712aee68b5a602b",
      "new_mode": 33188,
      "new_path": "tools/perf/builtin-trace.c"
    },
    {
      "type": "modify",
      "old_id": "dd51c6872a15c759d7f42d59bd4b5779ac7a325a",
      "old_mode": 33188,
      "old_path": "tools/perf/util/trace-event.h",
      "new_id": "e7aaf002e6679ec5599cfa6a39a09f3f6dbf7020",
      "new_mode": 33188,
      "new_path": "tools/perf/util/trace-event.h"
    }
  ]
}