This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [TAPSETS] Linux Kernel Event Trace Tool
- From: "Guanglei Li" <guanglei at cn dot ibm dot com>
- To: <systemtap at sourceware dot org>
- Cc: <jrs at us dot ibm dot com>
- Date: Fri, 16 Dec 2005 22:01:14 +0800
- Subject: Re: [TAPSETS] Linux Kernel Event Trace Tool
- References: <005c01c60215$fee77bf0$3585b509@IBM946B3A4365F>
Hien Nguyen wrote:
>2. Like Frank once commented,consider using printf for some of the
>logtrace functions,so we could emplement them in script instead of
>embeded C. For example, the log_tracedata_common() function could
>implement in script as follow
> printf("%d|%d|%d|%d|%d|%d\n", gettimeofday_ms(), pid(), ppid(),
> tid(), cpuid(), hoodID)
>
> [...]
>
>3. Consider using gettimeofday_s() for second, gettimeofday_ms()
> for millisecond, gettimeofday_ns() for naosenconds etc... They are
> new code under tapset, so you may not be aware.
>
---------------------------------------------------------------------
Thanks. In fact one reason of using embedded c tapsets is because I
can get values directly by accessing a variable, which is cheaper than
calling functions such as pid(), tid(), stp_pid() etc.
Another factor I considered is that some embedded c tapsets seem not
easy to be replaced by a equivalent stap script, e.g.
log_ioscheduler_tracedata_extra_elv_next(). To keep all my codes
consistent, I use log_tracedata_common() and log_tracedata_xxx_extra()
for all events.
Frank suggested making those embedded c functions to returns a string,
which the caller script routine could print, so that we can keep as
much logic as possible in script. The codes of mine hide the logging
details inside those embedded c functions. I am not sure which of
these two are better, any suggestions?