From mboxrd@z Thu Jan  1 00:00:00 1970
From: alexandre.montplaisir@polymtl.ca (Alexandre Montplaisir)
Date: Wed, 15 Jun 2011 01:23:17 -0400
Subject: [ltt-dev] UST communication library
In-Reply-To: <4DF7D1F6.5000402@polymtl.ca>
References: <4DF7D1F6.5000402@polymtl.ca>
Message-ID: <4DF841C5.6070508@polymtl.ca>

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