systemtap GUI Requirements

[Ryan Morse]

Hien Nguyen wrote:
> 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.
>
I agree that these are both sections that should be included, and will 
add them to the next revision.
>>
>> 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.
>
As Hien said we are starting off with an IDE to give people the ability 
to easily create scripts.  As we move forward we intend to add 
additional features that will make the GUI more functional.  For 
instance, once we have a working IDE we plan to implement a charting 
component for users to visually see what is happening with a script.  
Once this framework has been established we hope to create a performance 
analyzer that would allow people do drill down and see what is happening 
with their system.  This was very briefly described in section 7.1.  It 
is listed as a Stretch Goal because the Speedteam is only here for 6 
months and we wanted to make sure we could finish what was laid out as 
requirements.
>> 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.
>
Since SystemTAP is still rapidly developing we started out developing 
tools that will help people to write SystemTAP components to become 
familiar with it.  Once there is more of a framework available adding 
components such as the Performance Analyzer to expand the GUI makes a 
lot of sense.
> 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?
By predefined functions and probe aliases we are referring to everything 
that is included in the default tapset.  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.
>> 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?
Since pointer dereferencing requires compiling in guru mode, our plan 
was just to check to see if the script contained any dereferencing of 
pointers and then unobtrusively warn the user about it.  It was mainly 
just to inform them that they were doing something that was potentially 
unsafe.
>> 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.
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.
>> 3.2: It says counting line no. is error prone, what is the relevance 
>> of counting line no. here?
It was just a reference to having to look through Kernel Source code to 
find the line you want.  Since almost all editors give you the line 
number anyway it doesn't need to be stated.
>> 3.3: What exactly you mean be in addition all items in the current 
>> file will be added to the tree?
Items such as newly created functions in the current file will be added 
to the function browser.
>> 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
>>
>
We will use these suggestions in working on the next revision of the 
Requirements Document.

Thanks,
-Ryan