From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29907 invoked by alias); 17 Feb 2006 06:53:11 -0000 Received: (qmail 29894 invoked by uid 48); 17 Feb 2006 06:53:07 -0000 Date: Fri, 17 Feb 2006 06:53:00 -0000 Message-ID: <20060217065307.29893.qmail@sourceware.org> From: "guanglei at cn dot ibm dot com" To: systemtap@sources.redhat.com In-Reply-To: <20060209035522.2307.fche@redhat.com> References: <20060209035522.2307.fche@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug translator/2307] binary tracing X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q1/txt/msg00538.txt.bz2 ------- 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.