This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linux kernel marker questions


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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]