[ltt-dev] Usage of relayfs specific operations in generic code
viktor.rosendahl at nokia.com
Mon Nov 23 04:33:37 EST 2009
> 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:
You are right, it was wrong of me to write "relayfs". I knew that LTTng
doesn't use the stuff in kernel/relay.c anymore. Actually,
kernel/relay.c has changed name to "relay interface", so relayfs doesn't
even exist anymore. I guess I wrote "relayfs" as an archaism; my
impression is that at least some of the ltt/ltt-relay* code is inherited
from the old relayfs.
> 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 ?
In principle it sounds good; it's always better to use the latest stuff
instead of doing archeology. The only problem is that I am currently
working with N900, which runs a 2.6.28 based kernel. I could of course
upgrade but I am not sure if I can get a recent enough kernel to run on
the kind of HW that I need. Beagleboard would be nice to use but it
doesn't have the transport hardware that I want to use. I will have to
think about it and consider the options.
More information about the lttng-dev