Re: [PATCH] tracing/function-branch-tracer: enhancements for the trace output

[Frédéric Weisbecker]

2008/11/27 Steven Rostedt <rostedt@xxxxxxxxxxx>:
>
>>
>>
>> One detail. If you get a trace through the "trace" file, you will have
>> no problem.
>> But if you cat trace_pipe, leaf functions are considered as nested.
>>
>> This is because iter->buffer_iter[iter->cpu]; is very often (always?)
>> false by using this file.
>> I don't know why yet....
>> But it makes the tracer unable to check the next entry to verify if it
>> matches its own return.
>
> That's because trace_pipe does not use an iterator ;-)  It is live stream.
>
> There's two cases: static read and consume.  On static read we can take
> our time and we iterate over the data in the file. The data does not get
> consumed so we use an iterator to traverse the data.
>
> The consume read will consume each entry as it reads it. We do not need an
> iterator for this because we are always reading the head of the file.
> After we read the data, that data is consumed and we read the next item.
>
> Hmm, I may need to make this apparent to the plugins like yours. This way
> you can do different things whether it is a static read or a consuming
> read.
>
> Perhaps the info now is what you already found out.
> "iter->buffer_iter[iter->cpu] will always be NULL when it is a consuming
> read. Intead you need to use:
>
> ring_buffer_peek instead of ring_buffer_iter_peek
>
> and
>
> ring_buffer_consume instead of ring_buffer_read
>
> This is the way you can use it:
>
> entry = ring_buffer_peek(iter->tr->buffer, iter->cpu, NULL);
> entry = ring_buffer_consume(iter->tr->buffer, iter->cpu, NULL);


Ok. Thanks, I will correct it by covering the two cases, like in
trace.c : peek_next_entry()
--
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/