This is the mail archive of the systemtap@sourceware.org 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: systemtap GUI Requirements


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?


> >> 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.

> and then unobtrusively warn the user about it.  [...]

(Isn't an "unobtrusive warning" an oxymoron?)


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


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