This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Linux kernel marker questions
- From: David Smith <dsmith at redhat dot com>
- To: Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>
- Cc: Systemtap List <systemtap at sources dot redhat dot com>, ltt-dev at shafik dot org
- Date: Tue, 29 May 2007 08:24:30 -0500
- Subject: Re: Linux kernel marker questions
- References: <46531C6E.3010502@redhat.com> <20070528182305.GD7882@Krystal>
Mathieu Desnoyers wrote:
* David Smith (dsmith@redhat.com) wrote:
Am I correct that unique marker names are not strictly enforced but
"uniqueness" is more of a convention?
Yes. A marker can be declared more than once, but bears the same
semantics and should have the same parameter types.
OK.
One problem this creates for systemtap is that systemtap's probe syntax
looks like 'kernel.mark("marker_name")' and
'module("module_name").mark('marker_name'). I believe with the current
code if a marker exists with the same name, format string, and flags in
the kernel and a loadable module there isn't any way to only enable the
marker in one place or the other - you can only enable both markers
(assuming the module is loaded). Am I correct?
Correct. It could be fixed by adapting _marker_set_probe, making it take
an optinional struct module* argument.
That might be useful. I can see situations where you would want to
enable a marker only in a specific module.
2) _marker_set_probe() expects the marker name, format string, and flags
that were specified when the marker was inserted. If marker names were
truly unique, I would really only need the marker name to enable a marker.
format string and flags are only there to make sure nobody writes
foolishly a "bad" probe without considering the reentrancy impact and
by expecting the wrong arguments. Note that passing a NULL format string
is valid and means that the probe will parse the string dynamicall,
therefore getting around the verification.
OK, so I can pass a NULL as the format string. I'm more worried at this
point about the flags than the format string, since I currently don't
have a way to retrieve the flags.
Since systemtap can compile modules for a kernel that isn't running, I
can't really use marker_list_probe() for getting a list of markers
present (even if the output of marker_list_probe() was more than just
printks). So, currently to get a list of markers for a particular
kernel, the code reads and parses the kernel/module '__markers_strings'
elf section, which gets systemtap the marker names and format strings.
(Getting the marker flags out of a kernel/module elf file is possible,
but won't be easy.)
Currently systemtap can only enable markers that used the MF_DEFAULT set
of flags.
Have you got any ideas on how systemtap (or any other program) can get a
list of all the data _marker_set_probe needs?
Hrm.. well, isn't this information is a __markers section, which points
to a __markers data section ? It seems to me that it could be extracted
from the binary too, just like the __markers_strings. Please keep in
mind that these sections and data structures will change in the
forthcoming markers version.
In the kernel that I built using your patches, I end up with a
'__markers' section (which basically contains the enabled state of each
marker), and the '__markers_strings' section, which contains the marker
names and format strings. The '__markers_data' section doesn't exist as
a separate section, it is just part of the data section.
Of course another problem I've got is that the definitions of the data
structures aren't available from user-space.
3) From systemtap's point of view, _marker_set_probe() doesn't return
enough error information.
Would there be any way of getting more detailed error information?
It will change in the new version. I guess we should rediscuss it once I
submit the new patches.
Great. Do you have any ideas on when you plan on submitting the new
patches?
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)