* Documenting kernel tracepoints
@ 2009-03-18 16:35 William Cohen
2009-03-18 16:44 ` Ingo Molnar
0 siblings, 1 reply; 3+ messages in thread
From: William Cohen @ 2009-03-18 16:35 UTC (permalink / raw)
To: Linux Kernel Mailing List
There are a number of tracepoints in the latest kernels, but not much
documentation on the tracepoints. If a very recent version of
systemtap is available on the system, a list of the probe points can
be obtained with:
stap -p2 -e 'probe kernel.trace("*") {exit()}'|sort
However, this only provides the names. It doesn't provide information
about what information the probe point provides or the arguments
available at the probe point.
Currently, a number of kernel functions and structures are documented
with embedded comments that are extracted with kernel-doc. Seems like
it would be reasonable to extend this to support tracepoints.
Any thoughts or comments about this approach?
-Will
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Documenting kernel tracepoints
2009-03-18 16:35 Documenting kernel tracepoints William Cohen
@ 2009-03-18 16:44 ` Ingo Molnar
2009-03-18 18:44 ` William Cohen
0 siblings, 1 reply; 3+ messages in thread
From: Ingo Molnar @ 2009-03-18 16:44 UTC (permalink / raw)
To: William Cohen, Steven Rostedt, Frédéric Weisbecker,
Peter Zijlstra
Cc: Linux Kernel Mailing List
* William Cohen <wcohen@redhat.com> wrote:
> There are a number of tracepoints in the latest kernels, but not
> much documentation on the tracepoints. If a very recent version
> of systemtap is available on the system, a list of the probe
> points can be obtained with:
>
> stap -p2 -e 'probe kernel.trace("*") {exit()}'|sort
>
> However, this only provides the names. It doesn't provide
> information about what information the probe point provides or the
> arguments available at the probe point.
>
> Currently, a number of kernel functions and structures are
> documented with embedded comments that are extracted with
> kernel-doc. Seems like it would be reasonable to extend this to
> support tracepoints. Any thoughts or comments about this approach?
FYI, in the latest tracing tree (targeted for 2.6.30) all
tracepoints show up under /debug/tracing/events/.
Ingo
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Documenting kernel tracepoints
2009-03-18 16:44 ` Ingo Molnar
@ 2009-03-18 18:44 ` William Cohen
0 siblings, 0 replies; 3+ messages in thread
From: William Cohen @ 2009-03-18 18:44 UTC (permalink / raw)
To: Ingo Molnar
Cc: Steven Rostedt, Frédéric Weisbecker, Peter Zijlstra,
Linux Kernel Mailing List
Ingo Molnar wrote:
> * William Cohen <wcohen@redhat.com> wrote:
>
>> There are a number of tracepoints in the latest kernels, but not
>> much documentation on the tracepoints. If a very recent version
>> of systemtap is available on the system, a list of the probe
>> points can be obtained with:
>>
>> stap -p2 -e 'probe kernel.trace("*") {exit()}'|sort
>>
>> However, this only provides the names. It doesn't provide
>> information about what information the probe point provides or the
>> arguments available at the probe point.
>>
>> Currently, a number of kernel functions and structures are
>> documented with embedded comments that are extracted with
>> kernel-doc. Seems like it would be reasonable to extend this to
>> support tracepoints. Any thoughts or comments about this approach?
>
> FYI, in the latest tracing tree (targeted for 2.6.30) all
> tracepoints show up under /debug/tracing/events/.
>
> Ingo
The /debug/tracing/events provides event names and information about the
available arguments. However, it doesn't provide the detail comparable to
kerneldoc embedded comments summarizing the tracepoint's purpose or what the
arguments are.
-Will
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-03-18 19:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-18 16:35 Documenting kernel tracepoints William Cohen
2009-03-18 16:44 ` Ingo Molnar
2009-03-18 18:44 ` William Cohen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox