Re: Future of DTR?

["Frank Ch. Eigler" <fche at redhat dot com>]

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.

> 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

Attachment: pgp00000.pgp
Description: PGP signature