This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: architecture paper draft


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
	:
	;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]