RE: what is a tapset? [RE: Skeleton detailed design document]

["Chen, Brad" <brad dot chen at intel dot com>]

Thanks for the feedback on my note; very helpful.
Two follow-up items:

>On Fri, Apr 01, 2005 at 12:18:47PM -0800, Chen, Brad wrote:
>> [...]. Perhaps this is overly simplistic; is any of this 
>> incorrect? What parts are missing?
>
>Looks okay, except that I am not sure that the "tapset" constructs
>I've seen so far need *any* C code (custom headers or libraries).  I
>would like to see whether "tapsets" can be restricted entirely to 
>live within script fragments that the elaboration phase would pull 
>in. 
It makes sense to me that any tapset that simply used 
[kjr]probes could be done in script rather than C. I
agree this would be a good goal. Assuming it were so, 
it might be nice to compile the tapset defn once and 
reference an object file or library, rather than 
recompiling a potentially large body of script. In this
case you wouldn't need C includes for the tapsets, but 
you would need .o or .a inputs for the loader.

Here are some kinds of tapsets which might require C
code:
- time-based interrupts. I figure we'd want to have
  something like the DTrace "profile" provider which
  provides events like profile-100ms or profile-1sec.
  Seems like C code would be required for the underlying
  timer implementation. I could imagine putting an API
  into the Systemtap runtime along the lines of:
	/* invoke handler again in 100ms */
	ST_Interrupt(100ms, handler);
  Add a random[0..n) function that could be used to set
  the delay and I'd be even happier. Of course, we'd have
  to think through the safety considerations...
- event-based interrupts. This is a generalization of
  the time based interrupts to other hardware events
  the CPU can measure such as unaligned memory accesses.
  Configuring the PMU requires priviledged instructions.
- In general, different CPUs will have different 'special' 
  instructions. If tapsets could have C code, access to 
  these special instructions could go in a machine-dependent
  tapset. If not, we would have to build more machine
  dependencies into the systemtap runtime. CPUs will be 
  changing a lot in the next decade; it would be nice if
  Systemtap were ready for the changes.
- High-performance tapsets. It would be best if binaries
  from scripts was sufficiently fast that nobody would
  want to use these.

>>   It might be nice if jprobes were responsible for most/all
>>   resolution of kernel symbolic info.
>
>jprobes by its nature can't do anything symbolic.
>Data access works by textual "coincidence" of signatures.
>Perhaps you need to elaborate.
Hmm... You are correct. Let me be more specific about
what I was thinking. Jprobes provide for instrumenting 
procedures and accessing procedure call arguments. Also,
Will has posted a couple examples of how to get an address 
from a procedure name. For compile-time resolution, the 
elaborator could generate some C code like this 
(from Will's kprobe_schedule.c):
	/*For each probe you need to allocate a kprobe structure*/
	static struct kprobe kp = {
	        .pre_handler = inst_schedule,
	        .post_handler = NULL,
	        .fault_handler = NULL,
	        .addr = (kprobe_opcode_t *) schedule,
	};

For runtime resolution, Will's kprobe_funct_where.ko 
appears to use kallsyms_lookup_name(). My kernel seems to
have a kallsyms_symbol_to_address. Rephrasing my question:
Is this adequate access to code symbols? It would be nice 
someday to be able to refer to file names and line numbers, 
but perhaps that should wait for a later release.

Brad