[ltt-dev] UST communication library
Alexandre Montplaisir
alexandre.montplaisir at polymtl.ca
Wed Jun 15 01:23:17 EDT 2011
Hi David,
Sorry if I missed it, but what is the ultimate goal with lttng-tools? Is
it to
A) Become the unified trace controller for LTTng (kernel) and UST
(userspace) tracers.
or
B) Become a generic trace controller which people could "plug" their
tracers into, and which would come with initial support for LTTng and UST.
If it's A) and only A), I'd say yank the separate "libust" and merge it
into lttng-tools' tree. This is what happened with "lttctl", which is
now statically built in lttng-tools, right?
However modularity is never bad, perhaps going with an architecture like
B) is better long-term.
Some suggestions:
> So the problem is where this lib should go? Here are the possibilities I've
> discussed with Mathieu:
>
> 1) Keep libustcomm in UST and linking it in lttng-tools. Cons : direct
> dependency! ... not good
1b) Have an *optional* dependency on UST. At configure time, lttng-tools
could check if libust is present, if so compile it with UST support. If
not, only compile with kernel support. ("Warning, libust not found, UST
support will not be available", something like that)
> 2) Move libustcomm in lttng-tools and linking it with UST. Cons: direct
> dependency! ... not good
Indeed, the dependency would now be two-ways, might as well use 6) at
this point.
> 3) Keep libustcomm in UST and dlopen() functions in lttng-tools. For that, we
> will need an exported header that contains the symbols. So again... getting some
> sort of dependency! (header in UST or git tree)... not good
Similar to 1), but you still have a compile-time dependency.
> 4) Copy& Paste technique into both trees. REALLY NOT GOOD!
*cough* sdt.h *cough* ;)
> 5) Making it a standalone library. So, new git tree, new package and getting it
> dependent on lttng-tools and UST.
>
I'm not sure I get this one. Is there a point for an application to use
libustcomm standalone, without the rest of libust? If not then they
should be kept together, no?
And I'd add 6), as mentioned before:
6) Drop the separate ust/libust package and merge it with lttng-tools.
In my humble semi-outsider opinion, if you want goal A) I'd say go with
6), if you want goal B) go with 1b)
Cheers,
--
Alexandre Montplaisir
DORSAL lab,
École Polytechnique de Montréal
More information about the lttng-dev
mailing list