Re: Building a tracing userspace tool in the kernel tree
From: Chris Friesen
Date: Thu Oct 09 2008 - 19:11:53 EST
Peter Zijlstra wrote:
On Thu, 2008-10-09 at 16:35 -0600, Chris Friesen wrote:
Peter Zijlstra wrote:
On Thu, 2008-10-09 at 15:16 -0400, Mathieu Desnoyers wrote:
At the kernel summit, people seemed to be interested to have the basic
userspace tools required to extract and pretty-print a trace available
within the kernel tree. Therefore, what I am trying to do is something
along the lines of
ltt/usr/
ltt/usr/tracectl/ (control tracing)
ltt/usr/tracesplice/ (splice buffers to disk)
ltt/usr/tracecat/ (merge sort and format the binary buffers into
human-readable text)
I'd rather have you provide that interface from the kernel much like
ftrace does. So we can do:
# cat /debug/tracing/lttng/trace
Do we really want to reserve memory in the kernel to store all the data?
Assuming not, do we really want to have to deal with filesystem
namespaces in the kernel when interpreting which file we want to log to?
Not quite sure I get what you mean here. The kernel already needs the
memory anyway, as we keep the trace buffers in memory in either case.
All this does is provide a debugfs interface that does the exact same
thing the tracecat proglet would otherwise do.
I don't know how filesystem namespaces and debugfs interact, but seeing
as non of the debugfs users seem to be bothered with that, I don't see
why we should be.
Maybe I misunderstood something. I was under the impression that the
standard LTT usage is to stream raw trace data to disk and then
post-process it. If we're writing to disk, we should probably think
about filesystem namespaces.
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/