This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
is systemtap's language more complicated than needed.
- From: "James Dickens" <jamesd dot wi at gmail dot com>
- To: SystemTAP <systemtap at sources dot redhat dot com>
- Date: Wed, 13 Dec 2006 15:35:30 -0600
- Subject: is systemtap's language more complicated than needed.
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=BFDWIVFpFwlM+F+s75duvYjSi3gD/GPFxW7ZDbwbryg/SKQvrhF0UOnJS3iIA88HQ7VGgtsiL8yHUqpxGMlZqzETEthkown8/BLt3qphNfIlSQ+3dts/A4hNJVj3zYZ1mtQ1Mci0g2g3foQIcRGsnUfWnVmCFoVfEjTIN2pMeCU=
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