From: laijs@cn.fujitsu.com (Lai Jiangshan)
Subject: [ltt-dev] sub roadmap for text output
Date: Thu, 11 Dec 2008 14:44:57 +0800 [thread overview]
Message-ID: <4940B6E9.3070006@cn.fujitsu.com> (raw)
In-Reply-To: <20081210122235.GB28524@Krystal>
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,
>
next prev parent reply other threads:[~2008-12-11 6:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-10 4:55 Lai Jiangshan
2008-12-10 12:22 ` Mathieu Desnoyers
2008-12-11 6:44 ` Lai Jiangshan [this message]
2008-12-26 9:50 ` Lai Jiangshan
2008-12-26 15:23 ` Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4940B6E9.3070006@cn.fujitsu.com \
--to=laijs@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox