systemtap GUI Requirements

[Ryan Morse]

Frank Ch. Eigler wrote:
> Ryan Morse <ryan@linux.ibm.com> writes:
>
>   
>> [...]
>>     
>>>> Pg 4: It says no easy way to view predefined functions, what
>>>> function means here?
>>>>         
>> [...] Since functions and probe aliases are mixed together there
>> isn't a very easy way for people to see everything that is already
>> available for them to use.  A situation we are addressing by
>> creating trees of available functions and probes.
>>     
>
> OK, but what is the source of this information?  Do you intend to
> embed a systemtap parser?
>
>
>   
Yes, currently we have written a parser to scan through and locate 
functions, probes, and the variables associated with them.  Unfortunatly 
to get all the information that we want we have to run the translator 
twice.  Once with -p1 and once with -p2.  If there was another option to 
have everything output in xml format that should improve performance on 
our end.
>>>> 3.1.1: It says embedded will be checked for unsafe dereference of
>>>> pointers. Exactly what we are planning to do here and how are we
>>>> checking these?
>>>>         
>> Since pointer dereferencing requires compiling in guru mode, our plan
>> was just to check to see if the script contained any dereferencing of
>> pointers 
>>     
>
> Yes, but how?  Do you intend to parse embedded-C code?  Dereferencing
> can hide under many guises there - you basically have to compile it.
>
>   
This was an idea that we were tossing around.  We don't have an method 
designed yet.
>> and then unobtrusively warn the user about it.  [...]
>>     
>
> (Isn't an "unobtrusive warning" an oxymoron?)
>
>   
We were thinking of just putting a note on the side bar at the 
corresponding line, similar to how eclipse warns about errors now.
>   
>>>> 3.1.3: What exactly you mean by periodically running the
>>>> translator? Will it be done in the background or foreground? [...]
>>>>         
>> It will run in the background so that the user isn't hung up by it.
>> Right now we plan to run the translator when they save their document
>> in order to inform them of any errors in what they have written.  We
>> are open to suggestions about when to have it run.
>>     
>
> Running the translator to the -p1 or -p2 stage takes very little time
> and need have no side-effects, so it could run "constantly".
>
> If eclipse were to take advantage, we could have a special mode that
> makes it spit all available data out in (say) XML form.  You could use
> the translator's parser to scan the tapset, and write some eclipse
> code consume an XML parse tree containing all available
> probes/functions.
>
> Similarly, you could run the translator in -p2 mode to catch semantic
> errors such as type/symbol problems.
>
>
> As for Vara's idea of a system monitoring "dashboard", I agree it
> would be an interesting and ambitious thing.
>
> Such a widget would be very different from the script-authoring or
> kernel-source-browsing eclipse views being currently contemplated.  It
> would probably involve a specifically written (eclipse?) program,
> perhaps looking like one of many gui "system monitor" tools like the
> kde/gnome panels.
>
> It would work together with a dozen or two prepackaged systemtap
> scripts, running several copies of systemtap as an implementation
> detail.  If the front-end portion is written with enough foresight, a
> subsequent project could open it up to extensions, but I wouldn't
> put an excessive focus on that angle at the beginning.
>
>
> - FChE
>