[ltt-dev] UST communication library

[Mathieu Desnoyers]

* Yannick Brosseau (yannick.brosseau at gmail.com) wrote:
> On 2011-06-15 11:32, Mathieu Desnoyers wrote:
> > and implement it in "ustcomm": a package upon which UST and lttng-tools
> > both depend.
> I don't think an "independant" package is logical.

Let's see....

> ustcomm does not exist outside of UST.

This is true.

> Since it does not have a value on its own, It
> should be part of UST.

If we think in terms of "does this ustcomm package have any other
users than UST ?", I agree that the answer is no. So if we base
ourselves only on the "value-added for other projects" criterion, then
your conclusion is logical. However, this is not the only criterion, as
I explain extensively below,

> Changing an dependency from UST to ustcomm is not
> removing any dependency, its just adding one more and it makes it harder
> to maintain.

It removes the dependency from:

lttng-tools -> libust

by splitting the dependency chain like this:

lttng-tools -> ustcomm
libust -> ustcomm

So this part of your argumentation does not hold: we are in fact
removing a dependency from lttng-tools to libust by creating a separate
"ustcomm" package/lib/header.

Now, although I agree with your argument about the "no value-added for
other projects", we also have to consider how we want to handle
evolution of lttng-tools and libust through time and versions. Let say
we have a system with some programs linked against an old libust.so.0,
and other programs linked against libust.so.1 (and suppose we had to
break the API between libust and the application). Both libraries are
installed in the system, and both are in use. It is very likely that the
ustcomm communication does not have to change between
libust.so.0/libust.so.1, so both libraries can be controlled by the same
lttng-tools. Having a separate ustcomm package would handle transition
between libust API changes gracefully by allowing lttng-tools to
interact with the multiple compatible versions through the libustcomm
package used by both libust.so.0 and libust.so.1.

Now let's consider that we have a drastic protocol change in the
communication between lttng-tools and libust. We'd have to upgrade the
ustcomm along with both libust and lttng-tools, thus requiring that the
whole chain (lttng-tools and libust) must be upgraded. So ideally, we
want to keep the protocol as stable as possible, and ideally only
augment it with new commands instead of doing drastic changes when
ustcomm will be in place (or accept that both libust and lttng-tools
must be upgraded). My current plan is to proceed to a drastic protocol
change for the upcoming UST based on LTTng 2.0 (too many things are
changing to do it incrementally anyway: the ring buffer, CTF, new
tracepoint event API, multi-session handling), but keep it quite stable
afterward.

So basically, my point is that we should design this so we can do
changes in the API between libust and the applications without requiring
*all* applications to upgrade to the new libust to stay compatible with
lttng-tools.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com