From mboxrd@z Thu Jan  1 00:00:00 1970
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Date: Fri, 12 Dec 2008 09:13:42 -0500
Subject: [ltt-dev] [Fwd: Re:  sub roadmap for text output]
In-Reply-To: <49422064.1040609@cn.fujitsu.com>
References: <49418E7C.2000706@polymtl.ca> <20081211221627.GC6182@Krystal>
	<49422064.1040609@cn.fujitsu.com>
Message-ID: <20081212141342.GB3573@Krystal>

* Lai Jiangshan (laijs at cn.fujitsu.com) wrote:
> Mathieu Desnoyers wrote:
[...]
> > Lai wrote:
> >> 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.
> >>
> > 
> > Hrm, I think I have not been clear enough then. Sorry. My plan is to
> > iterate on every events directly in kernel. Those events will be stored
> > in ltt-relay buffers. We will _not_ use the poll() and ioctl() methods.
> > Instead, we will create new in-kernel APIs which will act _similarly_ to
> > those primitives. But everything will be in-kernel.
> > 
> > Those two different methods of accessing the buffers would be called
> > "data consumers".
> > 
> > (current) method 1:
> > - poll, ioctl, splice to export the data
> > 
> > (new) text output consumer :
> > - api to get events from a trace channel, merging the events by
> >   increasing timestamp
> > - exports the data to a userspace seq file (single stream per trace)
> 
> I understood. I had said, we need revise ltt-relay a lot:
> >>>> 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?
> But ltt-relay is so complicated that I can't write iterator for it.
> 

That's why I suggested that we first look at how ltt_ioctl and ltt_poll
works, because this is about the only thing we really need to understand
to create iterators. Because an iterator can be seen as a data
"consumer", and all the code that is responsible for synchronizing the
data consumption sits in ltt_ioctl and ltt_poll.

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68