[Bug tapsets/10745] New: Give access to "hidden" tracepoints

[Bug tapsets/10745] New: Give access to "hidden" tracepoints

[jistone at redhat dot com]

By "hidden" I mean tracepoints which are not exposed in a usable header.  This
might be because the header is not in include/trace/ or otherwise not packaged
in kernel-devel, or even when it is present it might be dependent on some
subsystem-internals.

The only way I know to really discover *all* tracepoints is through debugfs on a
live kernel.  That requirement doesn't really fit our general usage model.

I'm thinking instead to expose these as kernel.trace("foo").raw, analogous to
the kprobe.function("foo") which does no name checking.  If you specify an
incorrect name, you just won't get any hits, but no harm is done.

It's possible to register a handler without knowing the full callback signature.
 Instead of register_trace_foo(handler), we could imitate what that inline
really does with tracepoint_probe_register("foo", (void*)handler).

We couldn't know any argument names/types this way, but exposing $arg1, $arg2,
etc. as longs might be enough to be usable with @cast.  However, that assumes
though that passing a foo_handler(long, long, ...) with an incorrect number of
parameters wouldn't do any harm.

-- 
           Summary: Give access to "hidden" tracepoints
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: jistone at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=10745

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/10745] Give access to "hidden" tracepoints

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-12-01 14:42 -------
(In reply to comment #0)

> The only way I know to really discover *all* tracepoints is through debugfs on a
> live kernel.  That requirement doesn't really fit our general usage model.

Maybe we don't have to be too dogmatic about our usual method.  If we can eke
out a list of tracepoints from a running kernel, and use its running 
build-id/release to validate it against the target -r kernel, then the 
information can probably be relied upon.

(Of course, debugfs is sometimes not mounted.)


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10745

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/10745] Give access to "hidden" tracepoints

[wcohen at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wcohen at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=10745

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/10745] Give access to "hidden" tracepoints

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-03-18 21:29 -------
This sort of thing should work at some point:

probe perf.type(2).config(NN)

where NN comes from /debugfs/tracing/events/*/*/id

We could supply a shell script to parse the latter directory to come up with
a tapset correct for the currently running kernel.  Or the translator could
do it, and store it cached based on kernel build-id or somesuch.

See also /proc/sys/kernel/perf_event_paranoid


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10745

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/10745] Give access to "hidden" tracepoints

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-10-01 21:02 -------
I'm working on another approach that relies on extra header files
installed with the -debuginfo packages.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|systemtap at sources dot    |fche at redhat dot com
                   |redhat dot com              |
             Status|NEW                         |ASSIGNED


http://sourceware.org/bugzilla/show_bug.cgi?id=10745

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.