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

Viktor Rosendahl viktor.rosendahl at nokia.com
Fri Nov 20 10:56:22 EST 2009


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,
					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.

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?

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,


More information about the lttng-dev mailing list