* David Goulet ([email protected]) wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 11-06-15 11:06 AM, Yannick Brosseau wrote: > > On 2011-06-14 17:26, David Goulet wrote: > >> Hi everyone, > >> > >> We are in the process of moving out the UST control library out to > >> lttng-tools > >> (thus soon deprecating ustctl and usttrace from the UST git tree). However, > >> there is a common part which is the communication library (libustcomm) > >> where > >> every command to the tracer and responses are done through a Unix socket > >> using > >> that specific libs (that contains key functions to pack/unpack data). > >> > >> So the problem is where this lib should go? Here are the possibilities I've > >> discussed with Mathieu: > >> > > > > 7) Define a communication protocol and implement it on both side. That > > way, you have to library to depends on. > > > > This is a re-write of the actual code (will be the third time), code > duplication across two git tree and handling data function will be the > same both sides since it's a bidirectional communication. I really > think it's not the best way to do this. > > For this use case where two program needs to communicate together, we > need a third part communication library. So single point of failure, > single point to maintain and no dependency between packages, only the > lib, it's a trade off.
Reading through this thread, how about the following: 1) We define a protocol with: - A version number (used in a handshake) - Commands supported (listed in a header file) and implement it in "ustcomm": a package upon which UST and lttng-tools both depend. So if we install only libust, apps can link to it without having to install lttng-tools. If we choose to install lttng-tools, UST does not have to be there to control kernel tracing. ustcomm would be a hard dependency for both ust and lttng-tools. ustcomm is a bidirectional transport, but the protocol could define different commands in the different directions (lttng-tools -> libust and libust -> lttng-tools). Each command should be RPC-style with a return value indicating if the command succeeded (which is very close to the current libustcomm). No code duplication. It's just a refactoring of the current ustcomm, not a complete rewrite. Thoughts ? 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
