From mboxrd@z Thu Jan  1 00:00:00 1970
From: david.goulet@polymtl.ca (David Goulet)
Date: Wed, 15 Jun 2011 10:57:29 -0400
Subject: [ltt-dev] UST communication library
In-Reply-To: <4DF841C5.6070508@polymtl.ca>
References: <4DF7D1F6.5000402@polymtl.ca> <4DF841C5.6070508@polymtl.ca>
Message-ID: <4DF8C859.40904@polymtl.ca>

On 11-06-15 01:23 AM, Alexandre Montplaisir wrote:
> 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)

This is problematic for packaging...

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

Yep there is, to control the UST tracer. We want lttng-tools to be the one and
only tool for that but see this libustcomm as "an external module" to control
the ust tracer that lttng-tools uses.

> 
> 
> And I'd add 6), as mentioned before:
> 
> 6) Drop the separate ust/libust package and merge it with lttng-tools.
>

I'm not to comfortable with that. The thing is that we want to keep libust and
lttng-tools separate because it is not impossible to use ust *without*
lttng-tools thus libustcomm becoming a separate entity. However, for an INSANE
amount of features, use lttng-tools :).

Thanks Alex for this precious feedback!
David

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