From mboxrd@z Thu Jan  1 00:00:00 1970
From: laijs@cn.fujitsu.com (Lai Jiangshan)
Date: Thu, 11 Dec 2008 14:44:57 +0800
Subject: [ltt-dev] sub roadmap for text output
In-Reply-To: <20081210122235.GB28524@Krystal>
References: <493F4BB0.5070706@cn.fujitsu.com> <20081210122235.GB28524@Krystal>
Message-ID: <4940B6E9.3070006@cn.fujitsu.com>

Mathieu Desnoyers wrote:
> 
>> 2) ltt-relay events traveling
>>    current ltt-relay does not support iterator. it seems that ltt-relay is too
>>    complex to do this things. Is any plan to revise ltt-relay?
>>
> 
> ltt-relay task is to write data into buffers. I would create a different
> module which task is to do just like lttd does (get subbuf, read, put
> subbuf), but within the kernel. We might have to extend the API beyond
> the current ioctl/poll-based interface to allow in-kernel modules to do
> this.
> 
> Side-note : I think I would need to hook into open()/close() to keep
> refcounts on the channel reads rather that to use the get subbuf/put
> subbuf for refcounting. The currently implementation will behave a bit
> weirdly if multiple processes try to hook on the same trace channels.
> The resulting trace outputs will only each have part of the subbuffers.
> 

Very shocked!
I thought we should iterate very events directly in kernel, and merge them.
What you do is moving a user-space tool to kernel.

Any way, I will use these new APIs when they are applied.

>> 3) event reader
>>    get significative binary data from event. and convert them to a va_list
>>    or other type. binary in event is raw data, we must know its meaning for
>>    formating.
>>
> 
> The event reader is fairly easy to do. You fork from
> ltt/ltt-serialize.c, change it so it does binary to ascii conversion.
> It takes the format string as input. That's about it.
> 
>> 4) event text formator
>>    format data to text.
> 
> I am not sure how it differs from 3 ?

I think getting data and using data are two phases.

In Lttv
marker.c is the phase 1: event reader.
print.c is the phase 2: event text formator.

By the way: my patch for ftrace is also two phases.

> 
>> 5) create files for text output and control
>>
> 
> That will go on top of Zhaolei debugfs control implementation.
> 
>> In all, I think text output is urgency for lttng, but
>> "ltt-relay events traveling" is the bottleneck.
>>
> 
> Please tell me if you need more information or to discuss some elements
> more.
> 
> Best regards,
>