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

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

[Stone, Joshua I]

On Wednesday, December 13, 2006 4:33 PM, Frank Ch. Eigler wrote:
> "Stone, Joshua I" <joshua.i.stone@intel.com> writes:
> Indeed, and resolving this problem had been recorded as the goal of
> bug #1570.  Indeed, the issue is complicated by tension between the
> in-probability inline function returns and the compiler's propensity
> to inline things.

Ah, I thought there was a bug on that, but you caught me being too lazy
to go look... :)

>> 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. [...]
> 
> Perhaps, though we would be saving just two tokens ("." and "function"
> / "statement" / ...) for each such shorthand use.  Or one could save
> typing effort by supporting explicit abbreviations like "k.stmt(...)"
> for "kernel.statement(...)".

I don't think the current language is all that verbose.  The main value
I see in shortening it is for the benefit of one-liners.

Would it make sense to do this generally and provide some sort of
auto-completion?  For example if I say 'probe foo', and there is no
'foo', but the only possible expansion is 'foobar', it could be
automatically expanded.

Wildcards almost do this, except that auto-completion means to give
exactly one unambiguous match, rather than all matches.


Josh

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

[Frank Ch. Eigler]

Hi -

varap wrote:

> [...]  Although we wont be monitoring syscalls in the application
> systemcall tapset is correct in referring to kernel.syscall rather
> than just syscall [...]

Actually, syscall.* is the proper name - just like our many other
aliases that don't bother with a prefix (e.g., LKET, I/O, signals,
....)  Any instances of kernel.syscall that still remain constitute
unfinished work from an old bug.  However, a brief grep shows that in
fact no such instances still remain in CVS, except in one man page
where it was used for syntactic illustration only.

- FChE

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

[Vara Prasad]

James Dickens wrote:

> [snip]
>
>> Perhaps, though we would be saving just two tokens ("." and "function"
>> / "statement" / ...) for each such shorthand use.  Or one could save
>> typing effort by supporting explicit abbreviations like "k.stmt(...)"
>> for "kernel.statement(...)".
>
>
> and make the thing even harder to read? I hope this isn't the case. I
> started this thread because of readability not the length of the
> files.
>
> while we are talking about shortening things I did see one other
> change to the language, currently  there is  kernel.syscall  probes
> this should be shortened to syscall because there won't be userland
> syscalls we will be monitoring correct?

Although we wont be monitoring syscalls in the application systemcall 
tapset is correct in referring to kernel.syscall rather than just 
syscall to maintain consistency in the syntax. In other words all things 
in the kernel have kernel prefix even if they are unique.

>
> James
>
> '
>
>>
>> - FChE
>>

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

[James Dickens]

[snip]
> Perhaps, though we would be saving just two tokens ("." and "function"
> / "statement" / ...) for each such shorthand use.  Or one could save
> typing effort by supporting explicit abbreviations like "k.stmt(...)"
> for "kernel.statement(...)".

and make the thing even harder to read? I hope this isn't the case. I
started this thread because of readability not the length of the
files.

while we are talking about shortening things I did see one other
change to the language, currently  there is  kernel.syscall  probes
this should be shortened to syscall because there won't be userland
syscalls we will be monitoring correct?

James

'

>
> - FChE
>

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

[Frank Ch. Eigler]

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

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

Indeed, and resolving this problem had been recorded as the goal of
bug #1570.  Indeed, the issue is complicated by tension between the
in-probability inline function returns and the compiler's propensity
to inline things.

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

Perhaps, though we would be saving just two tokens ("." and "function"
/ "statement" / ...) for each such shorthand use.  Or one could save
typing effort by supporting explicit abbreviations like "k.stmt(...)"
for "kernel.statement(...)".

- FChE

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

[Stone, Joshua I]

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

is systemtap's language more complicated than needed.

[James Dickens]

I was reading through the systemtap manual and wondered why are there
so many types of kernel probes.

kernel.function
kernel.inline
kernel.statement

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. In fact by parsing the
line it mostly should be obvious which type it just has to lookup is
the function point a inlined function or a regular function. and it
should automaticly use  kernel.statement type probe if there is a ":"
in the probe point.

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 */

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. When its time to add in the userland probles they could be
based on the same syntax

user$pid("functionname")
user$pid("functioname[file]")
user$pid("src/memorymanagment.c:2314")


just a thought

James Dickens
uadmin.blogspot.com