systemtap GUI Requirements

[Hien Nguyen]

Vara Prasad wrote:

>
> Sorry for the delay in my review. This is a good start for the 
> requirements, i think these requirements are a good basic building block.
> I have divided my comments into two sections general and specific 
> comments to the doc.

First, thanks for reviewing this document.

>
> General:
> We need a section that specifies the h/w and s/w environment that is 
> needed to install the GUI, for example this section lists if one needs 
> to download Eclipse or not etc.

Yes, I am sure that we will state HW/SW requirement in the first code drop.

>
> I think we need to add a section called intended audience or 
> customers, that should cover who all e.g. kernel developers, sysadmins 
> etc. could use this and how would they benefit from the GUI vs the 
> existing command line.

In my opinion, this tool would benefit all users or at least this is our 
goal, but that just my opinion.

>
> If you look at what is the purpose of SystemTAP, it is a tool to do 
> functional and performance analysis in a production environment in 
> real time (realtime i meant here is almost instant to the happening of 
> an event). The customer base for SystemTAP includes all the way from 
> sysadmins to kernel developers. When i read through the document i got 
> a feeling that the proposed requirements are to develop an IDE for 
> people to develop systemtap scripts. 

We start with the IDE, but we would not stop with just an IDE. It is 
going to be more (visual analyzer, performance analyzer etc...). Some 
people would probably welcome the the IDE, others don't.

> This to me is useful but not really giving me a GUI interface for 
> functional and performance analysis (which is the goal of systemtap).  
> In my view GUI should present a dash board of various resources in the 
> system like memory, cpu, I/O, n/w, locks etc. 

Our IDE is not only for writing stap script, it would be a tool that 
helps users to build their own dashboard the way they want it.

> Once i have that i should be able to kind of watch how resources are 
> being used and should be able to freely drill down on any resource.  A 
> similar view can be done for applications using the application 
> specific tapsets behind the screens.
>
> For example if i have a high level question "my system is running low 
> on memory", the GUI should let me drill down on which process is 
> hogging the memory, once i figure out the process i should know be 
> able to get the details of from what are all the different memory 
> pools this process is allocating memory. Another related question i 
> may have (which many times Linux customers run into on x86) is i am 
> running out of lowmem, GUI should be able to let me find out who are 
> all the top 10 consumers of lowmem. Similarly for locking i should be 
> able to see who is holding what locks, what is the queue statistics 
> (min, max, avg etc.) on various locks.

It is in our plan to work on such GUI module (the performance analyzer 
or visual analyser) and that will address the above.

>
> GUI should use behind the screens systemtap and predefined scripts and 
> tapsets to gather the data. GUI should generate various probe modules 
> as needed to help user explore various system properties.  Unless a 
> user explicitly would like to develop their own probe scripts the 
> probe IDE interface should be mostly in the background. Hope this 
> gives an idea of what my view of SystemTAP GUI for the wide customer 
> base we are trying to serve.


I think otherwise, the IDE should be in the middle of everything
1. Create and launch systemtap srcipts, output go to the text console.
2. Create and launch GUI components, systemtap data is displayed in the 
GUI (dashboard, chart etc...).
3. A container for the above scripts and GUI components.

In another the words, we are building a tool that helps poeple to build 
stap scripts, systemtap GUI components.

>
> Specific:
> Following are the specific comments on the submitted document.

It was our preliminary doc. We will update the document with details as 
we work on this project.

>
> Pg 4: It says no easy way to view predefined functions, what function 
> means here?
> section 2.2: It says it should allow addition existing functions. It 
> is not clear what do you mean by existing functions.
> 2.3: In situations .. sentence can be made better. A suggested re 
> write is "In situations where long response times are unavoidable as 
> an example running systemtap with a large module, a visual cue will be 
> displayed it inform the user of the activity."
> 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?
> 3.1.3: What exactly you mean by periodically running the translator? 
> Will it be done in the background or foreground? How do you decide 
> when to run the translator? Can i make changes while the translator is 
> running? This part needs to be explained better to answer some of 
> these questions.
> 3.2: It says counting line no. is error prone, what is the relevance 
> of counting line no. here?
> 3.3: What exactly you mean be in addition all items in the current 
> file will be added to the tree?
> 3.3.1: Function browser: I am guessing your covering here built in 
> functions like log(), trace() etc. I look at these as library 
> functions for the systemtap language, similar to libc functions for 
> "C" language. When you take an "C" IDE, these library functions are 
> not shown in the source development but they are available under help, 
> i think we should follow that model? We shouldn't worry about showing 
> file where these functions are implemented. We should look at these 
> more as builtin functions of the language.
> 3.3.2: The tapset browser also shouldn't organize based on the 
> Folder->file->alias method, instead it should be arranged based on the 
> functional area of the kernel and applications.
> 3.4: Conditional filter selector: This section is not clear, are you 
> referring to conditional blocks like if, while etc. or some thing 
> else. An example would help understand this better. If you are 
> referring to if, while etc. i am not sure why you want to have a 
> filter selector for that as they are part of the language. In other 
> words you are not planning to provide GUI element to every basic block 
> of the language then why these conditional statements.
> 3.5: Traces: This section is not at all clear. After discussing with 
> Hien i understand the intention but document doesn't communicate that 
> intention. I would suggest adding some examples would help make this 
> section clear.
> 4.1: The only difference is .. sentence has two instead words.
> 4.2: The second paragraph says a new tapset will be developed that 
> specifies the functions that will format the data for GUI to plot. 
> This sentence is bit vague, what exactly you mean by the functions, 
> don't we already have builtin functions to format the data, adding 
> some examples would help.
> 4.4:  What is an event for the purpose of this discussion? Can you 
> give some examples.
> 5.1: This section states the user needs to have a basic understanding 
> of SystemTAP and Kprobes, why and what exactly the kind of knowledge 
> about these underlying technologies.
> 6.2:  Is there a product called Rationale for testing? I think there 
> is a product from ex-Rationale now IBM company for testing but i doubt 
> its name is Rationale.
> 7.1 The last sentence of  the first paragraph says " or the amount 
> certain things are accessed" , this is not very clear, suggest a 
> rewrite to make it clear.
> The second paragraph says it is not built into SystemTAP GUI, why not 
> make it as a panel in the GUI.
>
> bye,
> Vara Prasad
>