[ANNOUNCE] trace-cmd 2.6.1
From: Steven Rostedt
Date: Fri May 05 2017 - 19:54:46 EST
Announce of trace-cmd 2.6.1
It's been a while since I released any official version of trace-cmd, and
there's been lots of updates (although it took me a while to even push those up
to the repo). Here's a brief list of what's happened since 2.6:
--max-graph-depth has been added.
--ts-offset has been added.
For more details, see the man pages.
-I was added (no events with 'h' set)
-S was added (no events with 's' set)
--ts-offset was added
--tv2tsecs was added
--tsdiff was added
--debug (undocumented) for my use mostly.
Fixed the timestamp format issue (rounding error)
Fix build with NO_PTRACE=1
Make sure plog() gets to console before crashing
Do not call malloc or realloc and friends from signal handler
Lots of removal of malloc_or_die()
Use of set_event_pid and event-fork option. When available, use them instead
of writing in pid filters into the event and function filters. Also means
ptrace is not needed for tracing children.
trace-cmd start/record -n will now update set_graph_notrace
Filtering out trace-cmd recorder threads when filtering is used.
Add "%" (modulus) processing in print formats.
'~' is handled within print_flags
Auto completion for bash.
New "trace-msg" protocol for listen, added.
Use of /var/run and /var/lib instead of /usr/local/*
Some helpers for external users.
Force "NO_PYTHON=1" if swig is not installed
And there were other cleanups, bug fixes and enhancements. Also kernelshark got
some loving too.
Now, my versioning has been up to now pretty much haphazard in what I've been
doing. I'm finally getting around to fixing that too.
This is the 2.6.1 stable release of 2.6, which is where I'm also going to fork
my 2.7 development from. All new updates for v2.6 will go in the
trace-cmd-stable-v2.6 branch, and will not be released till there's a 2.6.2
ready. The first commit to the master branch on top of that will be a change to
create a 2.7.dev version, which will not be a tag. Only number releases will
be. When 2.7 is released, I will create a trace-cmd-stable-v2.7 which will
start at that commit for bug fixes only. The next commit in master after the
2.7 commit will be a change to make a 2.8.dev, where all new development will
be on top of that. This will make version numbers more meaningful. Only v2.6.1
will be a ".1" release in the master branch after this, as I'm starting the
process at this release.
I will try harder to keep master up to date, with the latest development. But
if you run "trace-cmd --version" and there's a ".dev" attached to it, that
means that your trace-cmd may be unstable. Only the full number releases will
go through full testing. I hope this makes sense.