This is the mail archive of the systemtap@sources.redhat.com 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: Notes from the systemtap BOF


* Karim Yaghmour (karim@opersys.com) wrote:
> 
> Michael Raymond wrote:
> >     IMHO event markers have meaning separate from their physical location.
> > If we have two markers within schedule() and I add an ad hoc one, it
> > shouldn't change the "identity" of the previous two.
> >     I think that each trace point should have a numeric ID and a textual
> > component associated with it.  Whether the textual part comes from the
> > kernel or is linked to the ID in some user space DB is of minor importance.
> > The ID by itself allows position independence and quick comparison.  It also
> > allows ranges to be enabled / disabled which seems more semantically correct
> > than a per-file approach.  The text by itself gives human readable meaning.
> > If we go with both of them than we should have a policy regarding the
> > normalization issues associated with their tuple.
> 
> Sorry, I strongly disagree. The fact of the matter is that for any
> markers infrastructure to be viable it needs to require zero maintenance.
> Having unique IDs (per file or throughout the kernel) is going to require
> maintainers to have their eyes going accross the source checking for
> consistency. That's not likely to fly.
> 

Not necessarily. Those unique ID can be registered dynamically in an
initialization function.

We could derive, dynamically, the numeric ID from a unique text ID. My
suggestion for a unique text ID would be :
(stringified)
KBUILD_MODNAME KBUILD_BASENAME event_name

Every registered text ID could then have its own numeric ID. In fact, we don't
even have to care about having many numeric ID mapping to the same text ID : we
just use numeric ID as an index to text IDs.


> If there has to be some form of uniqueness, then it's going to come from
> the name-tags. User-space tools can then do the rest. And if you add your
> own events for debugging, then it's up to you to update the user-space
> tools to know about them.
>

How do you get those "name tag" in the trace without assigning a unique ID to
them at some point ? I don't think repeating a "thisisautterlylongeventname"
more than a few thousand times is acceptable.

> As for range-enable/disable, this is a job for user-space. If you need to
> enable "process scheduling" and this is something that, for you, spans
> multiple files, then you can have this enable "process scheduling" flag
> in user-space enable multiple markers in multiple files in the kernel.
> The onus is on user-space, not kernel space.
> 

In a scheme where there is only a possibility of having per file events (not
kernel wide), the correlation between events that comes in different files but
should be seen as "the same" can be done in userspace.


I agree on the basic idea of Michael of the (name, id) per event tuple, but I
add this thought : the id can be derived from the name dynamically. It leaves us
with the name as an identifier for an event (which might include the location
(module name, base name) where this name is declared, which is semantically
clear.

Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 


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