[Bug translator/9771] Detecting probes classes system wide

[Bug translator/9771] Detecting probes classes system wide

[fche at redhat dot com]

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |fche at redhat dot com
         Resolution|---                         |FIXED

--- Comment #3 from Frank Ch. Eigler <fche at redhat dot com> ---
stap -l '**'
stap --dump-probe-types

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

[Bug translator/9771] New: Detecting probes classes system wide

[mjw at redhat dot com]

stap -l and stap -L are great if you know what kind of probes there are and/or
which processes have markers in them. But it is not easy to figure out the probe
classes and arguments/process names without some extra knowledge.

stap -l * is a start, but doesn't get you any further:

$ stap -l \*
begin
end
error
never

Ideally stap -l without any arguments would give you the probe classes (kernel,
module, timer, process, tapset aliases, etc) timer, and given a probe class
would give you the applicable arguments (kernel -> function, statement, etc,
module -> module names, timer -> jiffies, ms, profile, etc, process -> function,
argument, mark, etc, process.mark -> processes on system containing markers, etc.)

For processes and libraries with markers compiled in it makes sense to have a
system wide registry (directory?) where marker files can be placed describing
the process and the mark semantics (plus arguments).

-- 
           Summary: Detecting probes classes system wide
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mjw at redhat dot com


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

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

[Bug translator/9771] Detecting probes classes system wide

[scox at redhat dot com]

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


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

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

[Bug translator/9771] Detecting probes classes system wide

[scox at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|scox at redhat dot com      |systemtap at sources dot
                   |                            |redhat dot com


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

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

[Bug translator/9771] Detecting probes classes system wide

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-02-17 15:04 -------
> stap -l and stap -L are great if you know what kind of probes there are and/or
> which processes have markers in them.

We should support globbing on the process parameter (process("/bin/*")....)
to make this easier.

> Ideally stap -l without any arguments would give you the probe classes 

More concretely, -l could work by traversing the match_node tree in addition
or instead of making a -p2 run via a synthetic probe script fragment.  The
latter would still be necessary for wildcards that are *inside* probe point
arguments -- kernel.function("*").  For wildcards outside, traversing the
match_node tree should be fine.  (I would probably avoid allowing '-l' to
have an optional parameter, for compatibility with current parsing.)

The various combinations should be enumerated here for analysis to decide
on the best mechanism.


> For processes and libraries with markers compiled in it makes sense to have a
> system wide registry (directory?) where marker files can be placed

This doesn't sound that practical.  Would process path globbing as above
be sufficient?


-- 


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

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

[Bug translator/9771] Detecting probes classes system wide

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-02-19 18:02 -------
(In reply to comment #1)
> > For processes and libraries with markers compiled in it makes sense to have a
> > system wide registry (directory?) where marker files can be placed
> 
> This doesn't sound that practical.  Would process path globbing as above
> be sufficient?

Maybe, it was just an idea that seemed simpler than trying to do "globbing". For
globbing to be really useful IMHO it needs to use the PATH and it needs to
figure out which libraries are (dynamically) used that might contain markers.

-- 


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

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