From: Jens Axboe <jens.axboe@oracle.com>
To: linux-btrace@vger.kernel.org
Subject: Re: Documentation on the binary file format?
Date: Fri, 30 Jan 2009 07:39:36 +0000 [thread overview]
Message-ID: <20090130073936.GD30821@kernel.dk> (raw)
In-Reply-To: <4981F463.1050905@cesmail.net>
On Thu, Jan 29 2009, M. Edward (Ed) Borasky wrote:
> Is there some documentation on the binary file format out of "blktrace"?
> I'm interested in writing some post-processing routines that extend what
> "blkparse" and "btt" do, and there is a substantial disk space hit if I
> generate the "blkparse" output and post-process that. I'm also
> considering a network server that takes the binary data from a
> "blktrace" client and does the analysis "on the fly", rather than saving
> off a binary trace.
Look at blktrace_api.h, that basically defines the binary format and
API. In short, the binary trace is just a multiple of blk_io_trace{}
structures. Note that they are always in big endian format, so the
parser needs to convert them to machine local byte ordering first.
> A side question ... how likely are changes in the binary format? The
> language(s) I want to use -- Perl and/or Ruby -- are pretty flexible at
> re-factoring to match format changes, but I'd like to have a clue on how
> much maintenance activity I'm taking on.
Not very likely. If a new format is incompatible with existing tools,
the BLK_IO_TRACE_VERSION will change. So in your program, you basically
do:
if ((trace->magic & 0xff) != BLK_IO_TRACE_VERSION)
err;
for starters, and then later if you want to handle different versions,
you can just check for what version is reports and punt to the
appropriate handler.
--
Jens Axboe
prev parent reply other threads:[~2009-01-30 7:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-29 18:24 Documentation on the binary file format? M. Edward (Ed) Borasky
2009-01-30 7:39 ` Jens Axboe [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090130073936.GD30821@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=linux-btrace@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.