From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29855 invoked by alias); 4 Feb 2009 15:01:33 -0000 Received: (qmail 29369 invoked by uid 22791); 4 Feb 2009 15:01:32 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Feb 2009 15:01:22 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n14F1KVh028623 for ; Wed, 4 Feb 2009 10:01:20 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n14F1Js5017518 for ; Wed, 4 Feb 2009 10:01:20 -0500 Received: from [10.32.10.75] (vpn-10-75.str.redhat.com [10.32.10.75]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n14F1Ixm014093 for ; Wed, 4 Feb 2009 10:01:19 -0500 Subject: Preparing for a new systemtap release? From: Mark Wielaard To: systemtap@sourceware.org Content-Type: text/plain Date: Wed, 04 Feb 2009 17:09:00 -0000 Message-Id: <1233759677.2243.111.camel@fedora.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q1/txt/msg00336.txt.bz2 Hi, It might be time to push out a new release again. We do publish regular snapshots but people often just use the last released version. Seeing that there have been various fixes for newer kernels and lots of new and exciting stuff done since 0.8 maybe we should prepare for a 0.9 (or 0.8.1)? I added some stuff to the NEWS file and prepared some draft release notes below. Frank mentioned it would be nice to have a section on all the kernel versions stap is know to work. I added my own, but you can see I am pretty conservative. So what would be a good source for this. Can dejazilla extract them? I am not sure the process.mark(), sys/sdt.h and the dtrace compatible static marker script are fully baked yet (I am still struggling with getting all markers in hotspot visible myself). It seems important to make sure at least the sys/sdt.h macros are as we really want before recommending people try it out, so they don't need to unnecessary recompile their binaries when we update these. Are there any other known showstoppers? And please add stuff in the blanks spots below or to the NEWS file if you think I missed something (very likely there were 290 commits since 0.8). Cheers, Mark Systemtap 0.9/0.8.1 (?) !!! DRAFT !!! release notes = Systemtap frontend (stap) changes The stap "-r DIR" option may be used to identify a hand-made kernel build directory. The tool determines the appropriate release string automatically from the directory. For scripts that sometimes terminate with excessive "skipped" probes, rerunning the script with "-t" (timing) will print more details about the skippage reasons. Per-pass verbosity control is available with the new "--vp {N}+" option. "stap --vp 040" adds 4 units of -v verbosity only to pass 2. This is useful for diagnosing errors from one pass without excessive verbosity from others. For those that really want to run stap from the build tree there is now the 'run-stap' script in the top-level build directory that sets up the SYSTEMTAP_TAPSET, SYSTEMTAP_RUNTIME, SYSTEMTAP_STAPRUN, and SYSTEMTAP_STAPIO environment variables (installing systemtap, in a local prefix, is still recommended for common use). For a full overview of the stap frontend see man stap(1). = Systemtap client and compile server The systemtap client and compile server are now available. These allow you to compile a systemtap module on a host other than the one which it will be run, providing the client and server are compatible. Other than using a server for passes 1 through 4, the client behaves like the 'stap' front end itself. This means, among other things, that the client will automatically load the resulting module on the local host unless -p[1234] was specified. The client/server now use SSL for network connection security and for signing. The systemtap client and server are prototypes only. Interfaces, options and usage may change at any time. See stap-server(8) for more details. = Systemtap probe points changes function("func").label("label") probes are now supported to allow matching the label of a function. Serious problems associated with user-space probing in shared libraries were corrected, making it now possible to experiment with probe shared libraries. Assuming dwarf debugging information is installed, use this twist on the normal syntax: probe process("/lib64/libc-2.8.so").function("....") { ... } This would probe all threads that call into that library. Running "stap -c CMD" or "stap -x PID" naturally restricts this to the target command+descendants only. $$vars etc. may be used. process().mark() probes are now possible to trace static user space markers put in programs with the STAP_PROBE macro using the new sys/sdt.h include file. This also provides dtrace compatible markers through DTRACE_PROBE and an associated python 'dtrace' script that can be used in builds based on dtrace that need dtrace -h or -G functionality. For a full overview of all probes see man stapprobes(5). = Documentation SystemTap Tapset Reference Manual Standard tapsets included with Systemtap were modified to include extractable documentation information based on the kernel-doc infrastructure. When configured --enabled-docs a HTML and PDF version of the Tapset Reference Manual is produced explaining probes defined in each tapset. SystemTap Beginners Guide Systemtap now comes with a new Beginners Guide that walks the user through their first steps setting up stap, understanding how it all works, introduces some useful scripts and describes some common pitfalls. It isn't created by default since it needs a Publican setup, but full build instructions can be found in the wiki: http://sourceware.org/systemtap/wiki/PublicanQuikHowto An online version can be found at: http://sourceware.org/systemtap/SystemTap_Beginners_Guide.pdf = Miscellaneous changes Systemtap initscript is available. This initscript allows you to run systemtap scripts as system services (in flight recorder mode) and control those scripts individually. See README.initscript for details. Symbol tables and unwind (backtracing) data support were formerly compiled in for all probed modules as identified by the script (kernel; module("name"); process("file")) plus those listed by the stap "-d BINARY" option. Now, this data is included only if the systemtap script uses tapset functions like probefunc() or backtrace() that require such information. This shrinks the probe modules considerably for the rest. Most probe handlers now run with interrupts enabled, for improved system responsiveness and less probing overhead. This may result in more skipped probes, for example if a reentrant probe handler is attempted from within an interrupt handler. It may also make the systemtap overload detection facility more likely to be triggered, as interrupt handlers' run time would be included in the self-assessed overhead of running probe handlers. = The following people helped with code contributions for this release: Dave Brolley, David Smith, Don Domingo, Elliott Baron, Eugeniy Meshcheryakov, Frank Ch. Eigler, Jim Keniston, Josh Stone, Kent Sebastian, K Prasad, Mark Wielaard, Masami Hiramatsu, Rajan Arora, Roland McGrath, Srikar Dronamraju, Stan Cox, Tim Moore, Wenji Huang and Will Cohen = Range of kernel versions Systemtap has been tested on: 2.6.27.12 (f10/i386/x86_64) 2.6.18 (el5/xen/i386/x86_64) ... = Know issues with this release: ... = Bugs closed for this release: ... = Test results on various systems: ...