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


Mathieu Desnoyers wrote:
> 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.
...
> 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.

Sorry, but I don't see how my initial description could be interepreted as
wanting to log the actual tag string for every event. Here's from my
initial response to Charles:
> So, for example, the identifier of the lone marker inside schedule() for
> the scheduling change would be something like:
> "kernel/sched.c:schedule:1"
> The actual "ID" could be something like an md5 based on that string.
> Correlation between IDs and original string (the actual event) would be
> done in user-space.

Clearly, the "ID" would be a numerical value and the correlation between that
value and the original string is done in userland.

Using the event_name instead of the ordering within the function is still not
as fool-proof as the ordering. Basically, event_name requires that maintainers
still check the code for non-overlapping names (otherwise, what happens if
you've got two events declared differently within a same file but with the same
event_name?) Again, this is maintainership overhead. Really, we want markers
to have zero maintainership overhead.

> 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.

Yes, that's what I've been saying.

> 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.

Sorry, this is still an overhead on maintainers. It still requires them
to check whether two separate events have the same name yet different
declarations. Adding to the maintainers' workload is guaranteeing that
we'll show up as "enemy" on the radars of many. Let's not go there.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546


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