RE: Miscellaneous questions & comments

RE: Miscellaneous questions & comments

[Stone, Joshua I]

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

Re: Miscellaneous questions & comments

[Frank Ch. Eigler]

"Stone, Joshua I" <joshua.i.stone@intel.com> writes:

> [...] 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.).

If so, is it obvious which name a user script might want to see for
a scenario that includes multiple wildcard expansions and aliases?

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

We should come up with a project logo/slogan, and have cafepress
makeup some swag.

- FChE

Re: Miscellaneous questions & comments

[Vara Prasad]

Mike Mason wrote:

> I've been jotting down questions as I've been collecting info for the 
> Tapset Writer's Guide.  It's about time I ask some of them :-)
>
> - 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?

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

Same here.

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


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

>
> - Is there any way to do tapset versioning?  I can envision situations 
> where a script may want or need to do something different depending on 
> the version of the tapset.


Can you give some examples?  This may be an issue during these periods 
where tapsets are still evolving but as an end user i don't want to deal 
with the complexities of tapset versions. I want to write a script and i 
expect it to work across all the platforms (assuming i am not probing 
platform specific code) using any supported version of systemtap. I 
understand this may not be possible at this time due to rapid evolution 
our project is going through but as far as i know we are trying to 
provide backward compatibility to prevent such failures.

>
> - It would be nice to be able to pass back more than one value in a 
> function.  For example, the tokenize() function I recently wrote 
> should ideally pass back a token and a pointer to the beginning of the 
> next token.  Since systemtap doesn't have a "pass by reference" 
> capability, I can't pass back the next token pointer.  I have to keep 
> that pointer as a global, making the function non-reentrant.  Any 
> chance we could add "pass by reference" in the future?

I personally think we shouldn't introduce complexities such as pass by 
reference in a scripting language, we will be loosing the simplicity of 
the language we have now. Isn't that the case with most scripting 
languages like awk, PERL, Shell etc.

>
> - This may be too "blue sky", but it would also be nice to have 
> structures.  I've run into several situations where an array of 
> structures would have made things easier, rather than one array for 
> each element in the structure.

I always thought we should support structures to make it easy and if i 
understood correctly Frank is not opposed to this idea in principal but 
wanted more evidence of such a need before he takes on the complex task 
of structure support. Can you give few examples of where you feel you 
need structure support and how difficult it is to do the same thing  
now. I think that will help in shedding more light into this problem.

>
> That's all for now.
>
> Mike Mason
>
>
>

Miscellaneous questions & comments

[Mike Mason]

I've been jotting down questions as I've been collecting info for the Tapset Writer's Guide.  It's about time I ask some of them :-)

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

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

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

- Is there any way to do tapset versioning?  I can envision situations where a script may want or need to do something different depending on the version of the tapset.

- It would be nice to be able to pass back more than one value in a function.  For example, the tokenize() function I recently wrote should ideally pass back a token and a pointer to the beginning of the next token.  Since systemtap doesn't have a "pass by reference" capability, I can't pass back the next token pointer.  I have to keep that pointer as a global, making the function non-reentrant.  Any chance we could add "pass by reference" in the future?

- This may be too "blue sky", but it would also be nice to have structures.  I've run into several situations where an array of structures would have made things easier, rather than one array for each element in the structure.

That's all for now.

Mike Mason