[ltt-dev] UST communication library

[Mathieu Desnoyers]

* David Goulet (david.goulet at polymtl.ca) 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