This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC: ideas for release notes for the next release


Hi,

We wanted to push out a new (0.9.6?) release this week.  Below are
some suggestions for the release notes. Please read through them and
suggest additions/fixes.

The systemtap team announces release 0.9.XXX.

= Where to get it

   http://sourceware.org/systemtap/ - our project page
   http://sourceware.org/systemtap/ftp/releases/systemtap-0.9.XXX.tar.gz
   git commit release-0.9.XXX

= How to build it

   See the README and NEWS files at
   http://sourceware.org/git/?p=systemtap.git;a=tree
   Further information at http://sourceware.org/systemtap/wiki/

= Systemtap frontend (stap) changes

- The --skip-badvars option now also suppresses run-time error
  messages that would otherwise result from erroneous memory accesses.
  Such accesses can originate from $context expressions fueled by
  erroneous debug data, or by kernel_{long,string,...}() tapset calls.

  For a full overview of the stap frontend see man stap(1).

= Systemtap script language changes

- @cast can now determine its type information using an explicit header
  specification.  For example:
    @cast(tv, "timeval", "<sys/time.h>")->tv_sec
    @cast(task, "task_struct", "kernel<linux/sched.h>")->tgid

- The overlapping process.* tapsets are now separated.  Those probe
  points documented in stapprobes(3stap) remain the same.  Those that
  were formerly in stapprobes.process(3stap) have been renamed to
  kprocess, to reflect their kernel perspective on processes.

- New probes 'kprobe.function(FUNCTION)' and
 'kprobe.function(FUNCTION).return'  for dwarfless probing. These
  postpone function address resolution to run-time and use the
  kprobe symbol-resolution mechanism. Probing of absolute statements
  can be done using the kprobe.statement(ADDRESS).absolute construct.

= Code contributors for this release

  Ananth N Mavinakayanahalli, Andre Detsch, David Smith, Eugene Teo,
  Eugeniy Meshcheryakov, Frank Ch. Eigler, Jim Keniston, Josh Stone,
  Kent Sebastian, Mark Wielaard, Masami Hiramatsu, Maynard Johnson,
  Prerna Saxena, Roland McGrath, Stan Cox, Sunzen Wang, Tim Moore,
  Wenji Huang, William Cohen

= Examples of tested kernel versions

  2.6.9-70 (el4/i386)
  2.6.18 (el5/ia64/i686/x86_64-xen)
  2.6.27.21 (f10/i686/x86_64)
  2.6.29 (i586/x86_64)

= Know issues with this release

  Some kernel crashes continue to be reported when a script probes
  broad kernel function wildcards.

  Some 2.6.28- and 2.6.29-era kernels contain bugs that can more
  easily trigger crashes upon systemtap scripts.  Upgrade to the
  latest -stable or -rc if possible.

= Problems resolved for this release

  PR10055  generate dummy modules w/types for @cast
  PR10078  uretprobes on functions returning structs/unions
  PR7072   use _stp_reserve_bytes for printf buffer
  PR9953   split up the two process.* tapsets
  PR10070  don't warn about side-effect-free probes in -t (timing)
           mode
  PR10067  fix bitfield access when used with @cast
  PR10049  restore better errors for $return
  PR9940   avoid double calling of uprobes in shared libraries
  PR10026  read marker/tracepoint args directly
  PR10037  add target_symbol token to $context error messages
  PR5163   assign need_uprobes during pass-2
  PR10032  trigger cleanup after relay thread errors
  PR6580   implement symname, symdata and modname context functions
  PR9995   test for [installtest_p] && [utrace_p].
  PR10019  add --skip-badvars to suppress run-time memory errors too
  PR4105   support up to 9 (up from 5) array index dimensions
  PR10016  purge stap of all pgrp and system() usage
  PR10020  sys_sigaltstack param change
  PR10016  run stap in its own process group with waiter process for
           signals
  PR9998   adapt tapset/i686/registers.stp to latest kernel

= Test results on various systems

  After running "sudo make installcheck" from the test suite, on a
  suitably equipped machine (kernel debugging data and other stuff
  installed), you should see 500-600 passes and a small handful of
  failures.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]