[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090119232956.GD6194@nowhere>
Date: Tue, 20 Jan 2009 00:29:56 +0100
From: Frederic Weisbecker <fweisbec@...il.com>
To: Arnaldo Carvalho de Melo <acme@...hat.com>,
Lai Jiangshan <laijs@...fujitsu.com>,
Ingo Molnar <mingo@...e.hu>,
Steven Rostedt <rostedt@...dmis.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/5] ftrace: infrastructure for supporting binary record
On Mon, Jan 19, 2009 at 07:37:21PM -0200, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jan 19, 2009 at 10:08:40PM +0100, Frederic Weisbecker escreveu:
> > On Mon, Jan 19, 2009 at 06:25:23PM -0200, Arnaldo Carvalho de Melo wrote:
> > > Em Mon, Jan 19, 2009 at 08:28:03PM +0100, Frédéric Weisbecker escreveu:
> > > > 2009/1/2 Arnaldo Carvalho de Melo <acme@...stprotocols.net>:
> > > > >
> > > > > warning: I haven't looked at the patch details
> > > > >
> > > > > But I would love to use something like this to provide the exact
> > > > > contents the userspace blktrace utilities want.
> > > > >
> > > > > - Arnaldo
> > > > >
> > > >
> > > >
> > > > Hi Arnaldo,
> > >
> > > > Since you talked about binary record for the blk tracer, I just recall
> > > > this patch. Are you sure this infrastructure would cover your needs?
> > >
> > > Nope, now that I look at it it definetely isn't what I need. See? the
> > > warning was valid after all :-)
> > >
> > > What I want and will experiment now is to almost dump the contents of
> > > the ring buffer as-is to userspace. I want that so that I can use
> > > blkparse to validate the ring buffer + blkFtrace routines produced
> > > buffer.
> > >
> > > So probably it will be a matter of using trace_iter to signal that, and
> > > when it gets to my print_line routine I just put together the initial
> > > trace format expected by blkparse + the ones I'm collecting at
> > > tracepoint time.
> >
> >
> > So you would like two different trace files? Or print both bin and formatted
> > output together in the same file?
> > I'm not sure I understand :-s
>
> output depends on iter_flags, most of what is needed is there, but I
> guess there are too many ways to achieve the same result and some
> keywords that are already used for other purposes, such as
> TRACE_ITER_BIN -> print_bin_fmt that forces all traces to first have
> pid, cpu and timestamp (all using trace_seq_putmem), then whatever the
> tracer wants to put after that (if it registered a tracer_event _and_ it
> has a ->binary() emitter), when I wanted it to just call ->binary(),
> where I would emulate exactly the old blktrace format, then we would be
> able to just ask for binary traces, collect them thru
> /d/tracing/trace_pipe and pipe them into blkparse for
> validation/debugging the ring_buffer + ftrace + blkFtrace code.
Oh I see. I think it just needs a new flag in struct trace_event to tell
if we want the headers or not.
And then check this flag in trace.c to decide if we print the cpu/time/pid
or let the tracer do all its job.
I will submit a patch in the next days to bring it.
> I'll try to get a brain dump in the form of working code later
> today/early tomorrow, now I'm being preempted by my wife to do those
> social things like having dinner and going to the movie theater 8)
Heh, have a good evening! :-)
> Regards,
>
> - Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists