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


Michael Raymond wrote:
>     I think we're getting closer to the issue but I likely got lost along a
> tangent.  Please forgive the missuse of tapset terminology.
>     Let's say that we have a tapset of core trace events such as a
> reschedule or handling an interrupt.  My understanding is that a mapping
> layer is proposed in user space to map tap physical location to actual
> meaning.  Everyone is happy.
>     Now I come along and want to do some additional ad hoc exploration.  I
> add a few tap points to the reschedule function and the core tap is no
> longer the first tap in the function.  I'm concerned that this is a 2-part
> exercise: add the ad hoc tap and change the user space mapping.  If I do
> this several times and then want to store and compare the results later, you
> can see why I'm concerned.
> 
>     Can we come up with a way to add ad hoc points that don't need to be in
> the mapping without having to update the mapping to point at the new
> physical locations?

Ah ok, I see the light :)

So remember those earlier flags I mentioned earlier (MARKER_PRINTK, MARKER_
TRACE, etc.)? Here's one more: MARKER_ADHOC.

In this case, the marker parser would create a list of adhoc trace points
per file (and, possibly also, per-function) and they would not have any
effect on the existing markers, their ordering, or how they are interpreted
in user-space. It would then be the users' job (or the tools' job if this
can be automated, and it should) to create the user-space matching between
the adhoc markers and the rest of the existing markers.

Having one more flag should be much more acceptable than having two
in-kernel definition schemes. Sure, you've got two ways of mapping markers
to real events once in user-space, but user-space should not be contentious.

Is this better?

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]