[ltt-dev] Usage of relayfs specific operations in generic code
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.
More information about the lttng-dev