Re: Linux kernel marker questions

Mathieu Desnoyers wrote:
> * David Smith ([email protected]) 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
[email protected]
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)