[Bug translator/2307] binary tracing

["guanglei at cn dot ibm dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From guanglei at cn dot ibm dot com  2006-02-17 06:53 -------
The following are my thoughts about binary trace interface. In a summary, I
prefer Martin Hunt's ideas.

The idea Tom proposed will bring the programming convenience and performance
improvement. But it has some problems:
 1. required to introduce struct into systemtap script language. 
 2. Inefficiency when refer to several fields of a struct target in different
assignments. e.g:
     ...
     trace_scsi.hostno = $cmd->device->host->host_no
     trace_scsi.channel = $cmd->device->channel
     trace_scsi.lun = $cmd->device->lun
       ...
     each reference to $target will generate a serial of function
calls(function__tvar_get_cmd, fetch_register, deref etc). This is why I don't
use printf directly in LKET in most cases, but use _stp_printf() in embedded c code.

 3. Another issue is that what will happen if some fields of a struct is a
string? e.g:
     trace_process_fork.processname = str_processname
    How should systemtap generate the corresponding struct? What's the size of
the string field of that struct?


So after thinking about this topic, I prefer what Martin Hunt proposed:
  (http://sources.redhat.com/ml/systemtap/2006-q1/msg00284.html)
  
It looks like a more generic interface, and it allows mixture of data
types(binary & string). We could implement it in the runtime lib, naming it
_stp_bin_printf(const char *fmt, ...). We could introduce a new function:
bin_vsnprintf based on the existing vsnprintf to support _stp_bin_printf, which
will directly assign the integer value instead of converting the integer into a
ASCII string. Of course we should modify stpd to let it support binary data
transfer, but I think BTI should already done about this, maybe only a slight
change is required.

Jose also implemented a feature which will use /proc to control whether the
probe handler should start/stop printing data. So we could also introduce
_lket_printf(const char *fmt, ...) using bin_vsnprintf which will check the
/proc to see if it should print data now and will also do some common work like
log_tracedata_common(). But I think start/stop tracing by /proc is useful and
should be incorporated into systemtap.

By having _stp_bin_printf/bin_vsnprintf/_lket_printf, we can introduce some
wrapper functions, such as lket_trace(). One idea is to introduce lket_print
into translator, just like print, so that we could using lket_print("%d%d%s%d",
int1,int2,str1,int3) in script directly.

I am not sure if I missed some points.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2307

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.