* Yannick Brosseau ([email protected]) 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 _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
