variables in scopes

[Vara Prasad]

Jim Keniston wrote:

>On Wed, 2005-04-13 at 13:25, Frank Ch. Eigler wrote:
>
>  
>
>>...
>>By coincidence, this reminds me...
>>
>>....
>>    
>>
>rpn and assembly language are also target-language independent, but
>nobody codes in them unless they have to.  The gdb expression parser
>already supports C expressions and most C++ expressions, which should
>take us a long way.  I can't imagine SystemTap succeeding without
>allowing access to kernel data structures using C syntax. 
>
>  
>
>>(Also, to express Uli's idea, var("filp") could be
>>parametrized with a scope up-count.)
>>
>>In the few spots where this would be statically sensible, values from
>>the systemtap variable space might be usable instead of literals:
>>@f->array[n]@ (with n in systemtap space rather than target space)
>>might map to
>>    index(field(var("f"),"array"),n)
>>    
>>
>
>Indeed, the @expr@ syntax doesn't provide access to systemtap variables
>without further tweaking.  If this feature is deemed important, then I'd
>suggest enhancing the systemtap parser to handle all C expressions, and
>support the following type of semantics:
>
>probe kernel.function("foo").entry
>{
>  local n;
>  probe f;
>  ...
>  ... f->array[n] ...
>}
>
>Here "probe f" means f refers to identifier f in the context of the
>probed function.  (We don't have to say "probe array" because the debug
>info can verify that array is a field of f.)
>
>"local n" means n is a script-local variable.  (By the way, I've always
>been uncomfortable with allowing the use of undeclared variables.  I've
>heard too many stories about typos in FORTRAN programs yielding
>disastrous results.)
>
>  
>
>>It may be possible to abbreviate this stuff with macros or more syntax
>>heuristics, but that might not be worth the loss of explicitness.
>>
>>
>>Note that most of this complication is associated with pointer/struct
>>traversal.  dtrace's answer to this is to allow typed pointers to be
>>an additional script-side data type.  Maybe we should consider this.
>>    
>>
>
>We really need to bite the bullet and parse full C expressions -- with
>the gdb parser's help or without it.  Don't make the "expert" script
>and/or tapset writer do the parsing for us.
>
>  
>
I think if we go the route of full "C" syntax we will not be any where 
close to what Dtrace offers in the area of ease of use. The most value i 
see in SystemTAP is knowledge of experts provided in the form of 
tapsets. The role of the language is an easy way to access those tapsets 
and data they provide. Once we develop decent set of tapset libraries 
most people including kernel developers for most of the common tasks 
find what is available in the library sufficient.  There might be 
occasions where one needs more than what is available and if you are a 
kernel developer you can always edit generated code and add what you 
need and make the module. If you are an end user even if the language 
allows without considerable kernel knowledge you wont be able to enhance 
the library anyway so it doesn't matter.

I would like to point out that recently in a customer situation some of 
the best Linux Kernel experts who have developed entire filesystems and 
major parts of the vm area etc. were trying to solve a performance 
problem along side the Sun folks. Sun folks using the Dtrace were able 
to narrow down the problem literally in less than 30 minutes and  Linux 
Kernel  folks couldn't figure out even for days.  These guys are Kernel 
experts, their main feedback to me was your Kprobe stuff is cool but not 
very useful without library that exports the data and a simple scripting 
language. I think we should not forget that language role is to make it 
easy to get what we want out of kernel. If we make this as a full blown 
c language, then i see where little difference in writing systemtap 
scripts vs kprobe modules.

Just my 2 cents.

bye,
Vara Prasad

>>- FChE
>>    
>>
>
>Jim
>
>
>  
>