lkml.org 
[lkml]   [2008]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Patch] Tracing/ftrace: Adds a marker to allow user comments

On Thu, 4 Sep 2008, Pekka Paalanen wrote:

> On Thu, 4 Sep 2008 18:20:09 +0200
> "Fr?d?ric Weisbecker" <fweisbec@gmail.com> wrote:
>
> > What is the best way to implement tracers's printk handlers?
>
> Your last message had an idea I didn't think before (or I misunderstood
> you), that there could be an optional callback for inserting markers
> into the ring buffer. My first thought was to have the usual entry
> handler (print_line callback) to format marker text when it is taken
> from the ring buffer and read to user space.
>
> > Do you think that these functions must be implemented in trace.c or is
> > it more relevant to dispatch the message to
> > a function provided by the current tracer in its struct tracer
> > operations? If such handler is not implemented, we just defaults the
> > formatting like ftrace_printk does.
>
> For the output formatting case, I'd prefer the print_line callback,
> it's just one more case for an entry type in there. Notice the
> difference between writing to ring buffer and reading to user.
>
> The trick is, when does mmiotrace sanitize the marker text, when it
> comes from user space, the debugfs file. Either
> a) have another callback for inserting messages into the ring buffer
> b) have a customisable trace_seq_print_cont()
>
> I think I'd favour b). When I tried to use trace_seq_print_cont(),
> I found it difficult to control the printing of \n at the end of
> message. So I would implement my own routine to handle also what
> trace_seq_print_cont() does, filtering the text while copying it
> to struct trace_seq. I'm not sure where this function should live.
> It could be useful to all tracers, that want "one line per marker
> entry" style output, so it could live in trace.c.
>
> So my suggestion is to put the marker text unfiltered into the ring
> buffer, and filter it (if required) during read to user (print_line).
>

For logdev (my pet project from way back, and the latest ftrace is based
on), I had a CUSTOM type. The API allowed to register a callback to a
type, and it would associate that type to some number (descriptor) and
pass that number back to you. Then you could use this number to write to
the buffer using the CUSTOM type and registered number. On output, when a
CUSTOM type is detected, it would read the custom.id (the number) and
search for any registered callbacks to handle the entry.

This probably would not be too difficult to implement. Especially since it
is already implemented in logdev.
(see http://rostedt.homelinux.com/logdev/)

-- Steve



\
 
 \ /
  Last update: 2008-09-04 20:13    [W:4.135 / U:0.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site