This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: architecture paper draft
- From: William Cohen <wcohen at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Fri, 28 Jan 2005 14:25:37 -0500
- Subject: Re: architecture paper draft
- References: <20050127212504.GH22921@redhat.com>
Frank Ch. Eigler wrote:
Hi -
I committed a first draft version of one proposed architecture in the
systemtap CVS repository. Check out the "archpaper" module using
anoncvs [1]. Or use a real ssh account so you can eventually contribute
directly (have you signed up yet?). Just for gags, temporarily
(since it's such an early draft) I put formatted version of the
LaTeX paper up at home:
<http://web.elastic.org/~fche/systemtap.pdf>
- FChE
[1]
cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/systemtap login
{enter "anoncvs" as the password}
cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/systemtap co archpaper
Hi Frank,
Thinking some more about the providers. I have written a silly little
grammar to try to flesh out the language and figure out to specify the
instrumentation schemes (or providers). I have attached the incomplete
grammar to this mail. I don't know if this will make things more or less
clearer.
Different instrumentation schemes are going to have different state
information available. There needs to be some semantic checking to make
sure that that state information is available in that probe. For
example a sampling mechanism operating like OProfile may cause a probe
to be triggered at any time. Thus, the probe may fire in an interrupt
service routine which doesn't have a valid current.
There are some fairly well defined interfaces for device drivers that
use struct with function pointers. It seems like it would be a
reasonable idea to have a instrumentation scheme that knows about the
layout of these structs to allow a developer to instrument functions
listed in the struct. This could be useful to determine whether a
performance problem is inside or outside the code for the physical device.
-Will
/* A embryonic grammar to thinking through describing probes language */
/* Attempts to use somethings like the syntax in AnTLR */
/* This grammar will need some massaging to be recursive desent (LL)
or automata capable with Bison/YACC (LR) */
/* Like C white space is not important in the language. */
/* Have comments like C in probe input the language. */
/* Tokens are in all upper case or in quotation marks, e.g.
STRING, "systemtap" */
instrumentation
: (probes)*
;
probe
: probe_specifier body;
probe_specifier
: "probe" instrumentation_scheme
;
instrumentation_scheme
: systemtap
| kernel_function_boundaries
;
systemtap
: /* What is run before the dynamic probes are inserted */
"systemtap" "." "init"
| /* What is run after the instrumentation is removed */
"systemtap" "." "fini"
;
kernel_function_boundary
: "kernel" "." function_list
;
function_list
: "function" "(" function_name_list ")"
;
function_name_list
: STRING ("," STRING)*
;
body
: "{" statements "}"
;
statements
: (statement)*
;
statement
:
;