Re: Future of DTR?

[William Cohen <wcohen at redhat dot com>]

Frank Ch. Eigler wrote:
> Hi -
>
>
>
> > I looked into the DTR tool last week, and played with it little bit. It 
> > is COOL. I thought we could use it as the framework for systemtap.  [...]
>
> The problem is that it's hard to call it a framework: it defines
> little software architecture or design.  I see it as more a mock-up
> of the overall flow: an existence proof that generated j/kprobes
> modules are likely to be workable.

DTR is cool. As Frank mentioned its main purpose was to prototype the 
step to go from an instrumentation script. The parsing of the 
instrumentation scripts is fairly simple minded. Martin mentioned that 
as he fixed a problem in the recognizer that a new problem would pop up. 
We do want to design a reasonable language rather than just keep hacking 
the current recognizer. Some of the operations that need to be done to 
check for safety are not going to fit into dtr textual translatoins.

DTR gives us some useful experience coding instrumentation, and could be 
used to write some simple instrumentation.

-Will

> > So my question is what is the future of DTR? 
>
>
> I believe Martin is not working on extending it further.
>
>
> > Do we really need a new language compiler/parser for systemtap?
> > or the just improving what we have in DTR is enough?
>
>
> (Actually, those two are not in theory mutually exclusive.)
> I believe that, yes, a real parser and translator is necessary.
> To do anything more complicated than the few-liner baby examples,
> the tool would have to analyze the incoming script, potentially
> deeply.  This parsing would enable the automation and safety.
>
> How exactly such parsing, analysis, translation code is written
> is a secondary matter.  I suppose one could do it in tcl and add
> this sort of mass to the dtr code, but ....  FWIW, I've tentatively
> settled on C++ bison/flex for the input end of the next prototype.
>
>
> - FChE