Re: user-space probes -- plan B from outer space

[Vara Prasad <prasadav@us.ibm.com>]

Frank Ch. Eigler wrote:

>Hi -
>
>varap wrote:
>  
>
>>[...]
>>    
>>
>>>A fixed pool of predefined handlers seem like an antithesis of
>>>systemtap.  Did you have some user interface in mind for these?
>>>      
>>>
>>Like i mentioned in response to Prasanna's user space probes approach  
>>mail there will be two types of handlers for user space probes [...]
>>    
>>
>
>I understand that this is what you're proposing.
>
>  
>
>>SystemTap will use the second approach.
>>    
>>
>
>OK, so no user interface required for the first.  But of course if
>you're building the first approach also, you must have some tool in
>mind to at least demonstrate it.
>  
>
I don't have any specific tool in mind but giving this interface 
satisfies the need for those who wants to write their own programs to 
trace user space without needing to use systemtap. I am not sure in 
reality how many people will do that but comments seem to ask for such 
an interface.

>
>  
>
>>[...] you could use the preexisting handlers and don't need to write
>>kernel module and possibly don't even need root permission to trace.
>>[...]
>>    
>>
>
>With some cleverness, we can keep separated the issues of these
>predefined handlers (and the hypothetical non-systemtap tool that
>might use them) and unprivileged probing.
>
>  
>
I am fine to keep the issues separate but if this lets us solve the root 
problem in limited cases we can use it until complete solution is found.

On the topic of the root problem, if i understand correctly the main 
reason we need root to use systemtap now is we need to load a module. 
One way to solve that is use pre-compiled modules but we have to deal 
with how we can parameterize them for the specific needs of a script. 
Another way to solve  this is someone comes up with a security model 
where we can designate certain types of modules are "safe" so non root 
users can load or  some security folks comes up with a fine grained 
roles in the system and we have a role that lets users to load systemtap 
kind of modules without needing root privileges.  None of these are easy 
implementations but who am i to say there are no better and easy to 
implement ideas.

>  
>
>>>>[...] I am not sure i see the value of process("process name")
>>>>syntax if our focus is process specific tracing.
>>>>        
>>>>
>>>It would be one way of identifying present or future processes to
>>>probe.  For processes that do not yet exist, what other scheme do you
>>>have in mind?
>>>      
>>>
>>The scheme i am thinking is you could start a new process [...]
>>    
>>
>
>But you were concerned about the process("name") *syntax*.  Sure,
>implementing any of these various probes may involve forked observer
>processes.  But if you don't have that *syntax*, how else do you want
>a script to target a particular process (other than by pid)?
>
>
>  
>
In the scheme i mentioned the syntax i was thinking is a command line 
option some thing like below
stap -e <myexecutable name>

In the above method when we start the process we get the pid and we can 
use the pid syntax so no need to have process("name") syntax to place 
probes. In other words if we are only go to allow process based tracing 
which meant to me as unique process id then what is the purpose of 
process ("name") which is not unique, may be i am missing something.

>>>>I am not sure i see lot of value of this solution compared to a gdb
>>>>batch job, but for bit better performance than the heavy weight gdb.
>>>>[...]
>>>>        
>>>>
>>>How would this gdb batch job alternative work?  Are you intending to
>>>compare the expressity of systemtap script with gdb macros?
>>>      
>>>
>>I am not saying gdb macros are as powerful as systemtap scripts. All i 
>>meant is one can use gdb batch scripts to print the variables you need 
>>and use all kinds of post processing using your favorite scripting 
>>language. As the handlers are run in the userspace i am not seeing much 
>>advantage of using systemtap language to do filtering in the userspace 
>>vs post processing using your favorite scripting language.
>>    
>>
>
>It has the same kind of advantage in user space as it does in kernel
>space: the option of safely and compactly
>filtering/analyzing/acting-on data in situ rather than archiving
>masses of trace data and passively analyzing it after the fact.
>
>  
>
No disagreements in use of systemtap language in kernel and doing it in 
situ. In the userspace however one can pipe the output to the post 
processing process without needing to write to disk.

>- FChE
>  
>