RE: is systemtap's language more complicated than needed.

["Stone, Joshua I" <joshua.i.stone@intel.com>]

On Wednesday, December 13, 2006 1:35 PM, James Dickens wrote:
> seems to be over kill, as an end user it would be easier if there was
> just one kernel probe type and let systemtap's parser figure out what
> exactly is needed to probe the right points. [...]
> 
> kernel("functionname")  /* either a  function or inlined, parser must
> figure it out */
> kernel("functionname[file]") /* either a  function or inlined, parser
> must figure it out */
> kernel("kernel/sched.c:2917")  /* a line in a file */
(Statement probes can also be raw addresses, but this kind of thing
would still work.)

I think what you're suggesting has some merit, and is also supported by
precedence in most debuggers -- i.e., to set a breakpoint you just state
the location, and the debugger resolves it as necessary.  I don't think
it's THAT painful to have to say kernel, inline, or statement, but I see
where you're coming from.

One reason that we distinguish between function and inline is because we
can't put return probes on inlines.  I think this is the original
motivation for the split.

There also the need to have some understanding of what placing a probe
entails.  With a function probe, you get one probe point, always in the
module where it's defined.  With an inline, it will likely resolve to
many points, perhaps not limited to any one module.  A function like
get_current(), while defined in the base kernel, will be instanced in
thousands of places across all modules.  It's a little reckless to do
that sort of expansion behind the user's back.

It gets really hairy when you account for wildcards.  You've
significantly widened the scope if probing kernel("*") means probing all
functions AND all instances of inline functions.

With that said...

> this change will make it much easier to read and create scripts for
> the end user, especially if a function is inlined at some point in the
> future.

This is a strong point in your favor, for the maintainability of scripts
and tapsets.  And given that the compiler might also inline functions on
its own, the function/inline distinction can be a real headache.

Perhaps we could implement what you suggest as a shorthand, but still
leave the function/inline/statement variants in place to allow one to be
explicit.

Anyone else have thoughts?


Josh