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

[Viktor Rosendahl]

Hi Mathieu,

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

best regards,

Viktor