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: Miscellaneous questions & comments


On Monday, December 04, 2006 4:08 PM, Vara Prasad wrote:
> Mike Mason wrote:
>> - Should the "name" variable be defined in every probe?  It's used
>> inconsistently in the current tapsets.  Some define it as the probe
>> alias name, some as the probed function name, some don't define it at
>> all. Given that we can use pp() and probefunc() to get the probed
>> function info, seems like probe alias name makes the most sense.  If
>> that's what we want, can we define a function similar to pp() and
>> probefunc() that returns the alias name?  Might be difficult given
>> that aliases can specify other aliases.
> 
> My suggestion would be unless there is a good reason let us make it
> consistent and agree upon one implementation. It is important for the
> script writer to know what they get at each probe point and if there
> is a common information at each probe point it is good to have
> consistency. Any disagreements on this?

Having a consistent name is a good idea.  We could ask tapset writers to
fill in name automatically, but this seems error-prone.  The translator
is very much aware of the aliases and how they resolve, so it could fill
this in dynamically as well.  This could be a new 'special' target name
($name, $alias, etc.), or it could be a new context function
(probename(), probealias(), etc.).  

>> - Should the "argstr" variable be defined in every probe?  Again,
>> that's not done consistently in the existing tapsets.
> 
> Same here.

This doesn't make sense for all probes.  It's fine for some, like the
syscalls, because the point of the tapset is to provide convenient
aliases and variables for the syscall functions.

The purpose of some other probes does not revolve around the functions
that they are aliased to.  For example, take "signal.send", which
resolves to four different functions.  An argstr wouldn't make sense
here, and it would limit the way we implement the tapset.  Right now
it's four functions, and we could make an argstr.  In some later kernel
though, it might be implemented with a marker probe, and an argstr
doesn't make sense anymore.

Part of the point of tapsets is to abstract the event away from the
functions.  You don't need to know how signal.send is defined -- you
just know that it will tell you when a signal is sent.  Having an argstr
just exposes the implementation, and that breaks the abstraction.

>> - How should we handle tapset probes that don't resolve on all
>> supported architectures?  For example, scheduler.ctxswitch probes
>> __switch_to(), which is marked with __kprobes on x86_64, but not on
>> other architectures.  Trying to use that probe alias on x86_64
>> results in a "no match for probe point" error.  Seems like something
>> more informative, such as "this probe not supported on x86_64" would
>> be better.  It there some way to mark the probe such that it emits
>> that type of error?

Please see the comments I made on bug #3634 -- it's for exactly these
portability reasons that I would like to get rid of that probe point.
http://sources.redhat.com/bugzilla/show_bug.cgi?id=3634

> This brings up couple of thoughts.
> 1) If it is not o.k to probe __switch_to on x86_64 is it really o.k to
> probe this function on other platforms. In other words shouldn't we be
> marking these kinds of functions that available across all the
> platforms with __kprobes on all the platforms?

The "systemtap.stress/current.stp" test covers __switch_to on all
platforms except x86_64 and IA64.  The only problem I recall with this
is bug #2091, and I'm not sure what the status of that is anymore...
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2091


> 2) Translator will eventually come across errors in probing the
> functions marked with __kprobes anyway so is it a good idea to
> automatically add the functions marked with __kprobes to the
> translator blacklist in every installation. If yes, i guess trick is
> to figure out what time during the life of systemtap we should do
> this automatic update so as to not to be out of sync with the debug
> info package updates. 

David fixed this at translation time -- see bug #2639.
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2639

(I feel like I should have a bugzilla sponsership after dropping all of
those links...)


Josh


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