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).


Cheers,
pq

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/