3 files changed, 0 insertions, 101 deletions
diff --git a/tapsets/dynamic_cg/dynamic_cg.txt b/tapsets/dynamic_cg/dynamic_cg.txt
deleted file mode 100644
index 35de29f1..00000000
--- a/tapsets/dynamic_cg/dynamic_cg.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-* Application name: Dynamic Callgraph
-* Contact: William Cohen, wochen@redhat.com
-
-* Motivation:
-
-Dynamic Callgraph would provide information to allow developers to see
-what other functions a function is calling. This could show that some
-unexpected functions are getting called. DTrace has a instrumentation
-provider that generates a trace of the functions called and returned.
-
-* Background:
-
-There have been times that people in Red Hat support have narrowed a
-problem to a specific function and the functions it calls.  Rather
-than instrumenting the function's children by hand, a tapset that
-provides a dynamic callgraph would allow quicker determination of the
-things called.  There are cases in the kernel code where determining
-the function being called cannot be determined statically,
-e.g. function to call is stored in a data structure.
-
-* Target software:
-
-Ideally both kernel and user space, but kernel space only would
-be sufficient for many cases.
-
-* Type of description:  tapset and scripting command
-  tapset to provide to support to capture call return information
-  scripting commands to turn on and off the capture
-
-* Interesting probe points:
-
-* Interesting values:
-
-* Dependencies:
-- P6/x86-64 processors have the debug hardware to trap control flow chgs.
-- Need to have the kernel maintain the debug hardware on a per process basis.
-       The DebugCtlMSR is not currently stored in the context
-	   (only debug registers 0, 1, 2, 3, 6, and 7 are virtualized)
-
-* Restrictions:
-  May be difficult to implement on ppc: returns may look like regular jumps
-      and trapping on all branches could cause problems with atomic operations
-  Won't work on pre p6 x86 processors
-  Won't provide data for inlined funcions
-
-* Data collection:
-  Track whether the instruction was a call or a return and the target address.
-
-* Data presentation:
-  -processing address in userspace to convert addresses into function names
-  -trace showing calls and returns
-  -maybe further post process to build dynamic callgraph
-	 determine that a function is being called way too often
-
-* Competition:
-  DTrace already implements tracing of function calls and returns.
-
-* Cross-references:
-
-* Associated files:
-
-  $dynamic_call_graph = 1; // turn on tracing of calls for thread
-  $dynamic_call_graph = 0; // turn off tracing of calls for thread
-
diff --git a/tapsets/dynamic_cg/tapset.stp b/tapsets/dynamic_cg/tapset.stp
deleted file mode 100644
index c731fac9..00000000
--- a/tapsets/dynamic_cg/tapset.stp
+++ /dev/null
@@ -1,7 +0,0 @@
-global $dynamic_call_graph
-probe kernel.perfctr.call(1) {
-   if ($dynamic_call_graph) trace_sym ($pc);
-}
-probe kernel.perfctr.return(1) {
-   if ($dynamic_call_graph) trace_sym ($pc);
-}
diff --git a/tapsets/dynamic_cg/usage.stp b/tapsets/dynamic_cg/usage.stp
deleted file mode 100644
index 1625768b..00000000
--- a/tapsets/dynamic_cg/usage.stp
+++ /dev/null
@@ -1,30 +0,0 @@
-
-probe.kernel.sys_open.entry()
-{
-  $dynamic_call_graph =1;
-}
-
-# What you would see in the output would be something of this kind
-# call sys_open
-#     call getname
-#          call do_getname
-#           return do_getname
-#     return getname
-#     call get_unused_fd
-#         call find_next_zero_bit
-#         return find_next_zero_bit
-#     return get_unused_fd
-#     call filep_open
-      .....
-return sys_open
-
-# The above probe could be customized to a particular process as well,
-# like in the following
-
-probe.kernel.sys_open.entry()
-{
-if ($PID == 1234)
-    $dynamic_call_graph =1;
-}
-
-