user instruction tracing patch?

[Dave Nomura]

Did you have any comments on the actual content of my patch?

Did you want to resolve the translator syntax changes to support 
instruction tracing first?

Most of the discussion regarding the translator syntax changes was 
beyond my understanding of SystemTap.  It sounded like some of the 
issues were broader than just instruction tracing.  Did you come to any 
consensus on what translator changes should be made?

Frank Ch. Eigler wrote:
> Hi -
>
>   
>>> [...]
>>>    probe program("/bin/vi").function("malloc")  { }
>>>
>>> would be a request to probe all running (and forseeably, any future)
>>> copies of vi.  To filter further, I imagine additional qualifiers such
>>> as ".pid(NUM)", ".uid(NUM)".  These are all to identify the potential
>>> probing target processes.
>>>       
>> In the above examples, if NUM could be a variable name, then I think
>> we're in business... especially if it could be a set of pids or uids
>> [...]
>>     
>
> Well, it depends how variable that data is.  Another way to think
> about it is to think of the probe point type of specification as
> "additive", and as conditionals as "subtractive".  If the data is
> fixed at/near startup time, then we can "add" probes only to the
> targeted processes and not bother any of the others.  If the data is
> highly variable, it may be more appropriate to designate probes in
> them all, and "subtract" out the uninteresting ones on the fly by
> means of dynamic disabling conditions.
>
> - FChE
>   


-- 
Dave Nomura
LTC Linux Power Toolchain