Re: [Patch] Tracing/ftrace: Adds a marker to allow user comments

[Steven Rostedt]

On Thu, 4 Sep 2008, Pekka Paalanen wrote:

> On Thu, 4 Sep 2008 18:20:09 +0200
> "Fr?d?ric Weisbecker" <fweisbec@xxxxxxxxx> 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

--
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/