Re: [Patch -tip 1/3] Tracing/ftrace: Relay unhandled entry output

[Pekka Paalanen <pq@iki.fi>]

On Thu, 25 Sep 2008 17:33:02 +0200
"Frédéric Weisbecker" <fweisbec@gmail.com> wrote:

> 2008/9/25 Pekka Paalanen <pq@iki.fi>:
> > IMHO this breaks the trace_seq handling. trace_seq may contain
> > the output of several entries, as far as they fit in it as a whole.
> > E.g. trace_seq_printf() does not print partial lines but returns 0,
> > so that the entry is not consumed right now. The user space reader
> > must consume trace_seq content, before trace_seq_printf()
> > is attempted again, hopefully with enough space in trace_seq to
> > succeed. See tracing_read_pipe().
> > print_line() callback works the same way. Returning 0 means "could
> > not print it this time, call me back later". You can't use that to
> > say "use the default output function instead". Note, that possibly
> > the default output function will fail, too, so it could actually
> > try many of the default output functions and still fail, eventually
> > leading by luck to the correct behaviour in most cases.
> > Note, that mmiotrace follows this convention: it deliberatly
> > returns 1 without processing when it wants the entry discarded, and
> > it returns 0 when there was not enough space to process the entry.
> > This is explained in my other email.
> 
> Hmm you're right. I didn't thought about the partial line which must
> not be printed.
> The problem is that with this convention, 0 means two things: "I will
> handle this entry
> later" or "I can't handle it".
> But if you return 0 because you can't handle it, and if the current
> len of the seq is 0, the
> pipe will be broken.

My understanding is that the pipe will be broken only, if the trace
framework believes tracing is disabled. Recall the discussion about
tracer_enabled = 0. Which is a bug, and I hoped Steven would have
commented on how to fix that properly.

Or was it fixed already, and this is a different issue?
I didn't notice.

-- 
Pekka Paalanen
http://www.iki.fi/pq/