[ltt-dev] Usage of relayfs specific operations in generic code

[Mathieu Desnoyers]

* Viktor Rosendahl (viktor.rosendahl at nokia.com) wrote:
> Hello,
>

Hi Viktor,

> I was trying to implement support for a Nokia specific HW transport when  
> I came across this lovely snippet of code in ltt-serialize.c:
>
> 		/* FIXME : could probably encapsulate transport better. */
> 		buf = ((struct rchan *)channel->trans_channel_data)->buf[cpu];
> 		/* Out-of-order write : header and data */
> 		buf_offset = ltt_write_event_header(trace,
> 					channel, buf, buf_offset,
> 					eID, data_size, tsc, rflags);
> 		ltt_write_event_data(buf, buf_offset, &closure,
> 					serialize_private,
> 					largest_align, fmt, &args_copy);
>
>
> It could be mentioned that both ltt_write_event_header() and  
> ltt_write_event_data() both uses relayfs specific functions. Also, I  
> think that the rchan struct is more or less specific to relayfs.

LTTng has stopped using relayfs a long time ago. We have all the
locking, allocation and vfs interface code within the ltt/ directory.
Note that I refer to the term "transport" as a combination of:

- locking scheme
- allocation scheme
- interface (e.g. vfs)

>
> To me this seems like the generic LTTng code is using relayfs specific  
> operations to write an event header and the data.
>
> Now I wonder, what is the proper way of tackling this problem?

A bit of history here:

In the past, LTTng transports could be chosen by specifying a callback
that would be called for space reservation and commit. This is however
too slow, as it adds unnecessary function calls to the tracing hot path.

Currently, the way this is done is by allowing to select the LTTng
locking scheme at build time (e.g. lockless, irqoff, spinlock+irqoff).
Recently, I dropped all schemes except lockless, because it was faster
to do lots of code changes in just one scheme.

Eventually, the goal is to permit to compile various kernel modules for
the different transports (and select any of these at runtime), _but_ not
require extra function calls. This will lead to duplication of some
objects, which will be compiled in more than one module with slightly
different parameters, but given we typically only use one transport at a
time, this should not be a problem.

So what I propose is that you work on the latest LTTng tree, changing
ltt-relay-alloc to suit your needs, possibly copying this file and doing
your work in a different C file, that could be chosen to replace
ltt-relay-alloc with the proper CONFIG option. If you need some extra
hooks to be called by ltt-relay-lockless.c to, for example, flush the
data out when a subbuffer is filled, then we can work on that together.

This first step would allow you to choose your own transport at build
time (the standard transport would not be available anymore). Then, when
we do the integration, we can work together to ensure that we allow
kernel modules for both transports to be compiled and we allow to select
between those at runtime.

How does that sound ?

Mathieu


>
> Should I add a couple of transport specific operations to the  
> ltt_trace_ops struct and try to move the relayfs specific functionality  
> into ltt-relay.c and ltt-relay-locked.c ?
>
> Are there any other places where transport relayfs code is used in those  
> parts of LTTng that one would expect to be generic ?
>
> Any other hints ?
>
> BTW, I am currently using lttng-0.88 on a 2.6.28 based kernel.However, I  
> checked that the same problem is still present in the very latest LTTng  
> in the git repository.
>
> Also, I saw that the problem was introduced in  
> patch-2.6.27-rc7-lttng-0.27.tar.gz, which was released in October 2008.  
> In other words, this issue has been present in the LTTng code base for  
> about a year, if I am not mistaken.
>
> best regards,
>
> Viktor
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>

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