RE: safety paper - please send feedback!

["Chen, Brad" <brad dot chen at intel dot com>]

G5 is included because it is a property of DTrace but
_not_ because I think Systemtap should be that way. The
"PROPOSAL" section provides a strawman for what we might 
do in Systemtap.

G15. I agree.

Getting a language specification would be an interesting
next step. Am I remembering correctly that Frank started
a grammar?

Brad

-----Original Message-----
From: systemtap-owner@sources.redhat.com
[mailto:systemtap-owner@sources.redhat.com] On Behalf Of William Cohen
Sent: Thursday, March 24, 2005 7:54 AM
To: Chen, Brad
Cc: systemtap@sources.redhat.com
Subject: Re: safety paper - please send feedback!

The "G5. No procedures" is a rather severe restriction. Depending on how

you count the runtime libraries it can't be enforced.
It would be better to generate a static call graph of the function calls

and verify there are no cycles. This will allow some factoring of code 
rather than having to inline everything. In most cases can live without 
recursive functions.

dynamic allocation could be done but only in the intial loading of the 
module and there must be checks to verify that it is successful. The 
probes themselves cannot do dynamic allocation.

G15.  "prefer mechanism that are intuitive to a programmer of
relatively ordinary skill." Lots of programmers of ordinary skill are
going to get things wrong.  There is a need to make it provable
to people, but there are lots of simple solutions that don't work in
the general case.  Theory and validation are still needed.

Definitely need to have a specification of the systemtap input language 
written that is concise.

-Will