[ltt-dev] UST communication library

[ltt-dev] UST communication library

[David Goulet]

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:

1) Keep libustcomm in UST and linking it in lttng-tools. Cons : direct
dependency! ... not good

2) Move libustcomm in lttng-tools and linking it with UST. Cons: direct
dependency! ... not good

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

4) Copy & Paste technique into both trees. REALLY NOT GOOD!

5) Making it a standalone library. So, new git tree, new package and getting it
dependent on lttng-tools and UST.

It seems that the fifth option should be the best idea...

Please any thoughts on that?

Cheers
David

[ltt-dev] UST communication library

[Alexandre Montplaisir]

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)

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


And I'd add 6), as mentioned before:

6) Drop the separate ust/libust package and merge it with lttng-tools.


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,

-- 
Alexandre Montplaisir
DORSAL lab,
?cole Polytechnique de Montr?al

[ltt-dev] UST communication library

[Nils Carlson]

Hi,

On 06/15/2011 07: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.
<snip>
> 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?
>
>
> And I'd add 6), as mentioned before:
>
> 6) Drop the separate ust/libust package and merge it with lttng-tools.
>
I agree with this. If we want UST to be hardwired into LTTng we should 
just merge UST into the LTTng repo completely.

I personally am not for this, I think it's a case of short-term 
expediency winning over technical merit. I think a modular architecture 
would be far nicer.

/Nils

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

[ltt-dev] UST communication library

[David Goulet]

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

[ltt-dev] UST communication library

[Yannick Brosseau]

On 2011-06-15 10:57, David Goulet wrote:
> 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...
No, this is not problematic. When we create a package, we just have to
build-depend on UST. That way, people who wants to build it by hand
without UST, don't need to install UST.
Also, for distro like gentoo, you can build your package with UST support.

Yannick

[ltt-dev] UST communication library

[David Goulet]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 11-06-15 11:01 AM, Yannick Brosseau wrote:
>>>> 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...
> No, this is not problematic. When we create a package, we just have to
> build-depend on UST. That way, people who wants to build it by hand
> without UST, don't need to install UST.
> Also, for distro like gentoo, you can build your package with UST support.
> 

Enlighten me Yannick :)

# apt-get install lttng-tools

How are you going to have the UST support without installing the UST package
(assuming that libustcomm is inside ust) ?

I figure you'll have a "Not found libust.so..." at execution time ?

David

> Yannick
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJN+My4AAoJEELoaioR9I026LwH/04zuhEKkhZq99qpRvdYAKtf
gIuNpr4T/mD+L+AOIcHhzDueCCZQmH7JZktlMycn4Ugkr8VKKDSvMfNTG8opOSmp
nfOgREJnLMCR8xifG9ry+UkhSWCVbKUnfXcknn2OVhe3ZqNkCZtJR5RAibqyYg+4
MTRhjCGvG2HjML2GPBtvrqmrTaJ6iVNFRdj/+qORGELED2vRqCXTlUb7bH69dr6X
Nok2XL9aPeXccFyzGoer/uS4XWm8OUOaFWdduQ3Zncwcqhw7U6oGUnPiikyW9AY0
JR1X0MN/yfdCYoV5xRI10+6bEHVERwDf0G1yTUxW/r+IaWPEae6qBjHNMzo+pzE=
=tcBC
-----END PGP SIGNATURE-----

[ltt-dev] UST communication library

[Yannick Brosseau]

> Enlighten me Yannick :)
>
> # apt-get install lttng-tools
>
> How are you going to have the UST support without installing the UST
> package
> (assuming that libustcomm is inside ust) ?
>
> I figure you'll have a "Not found libust.so..." at execution time ?

Exactly, for the *runtime* dependency, that would be a *recommand* and
we detect if libusb is present or not. But  that's really up to the
packager to decide how he does it. Each distro might have their own
policies.

As the upstream developer, you should let the user decide if he want UST
support or not. I might be building an embedded system were space is a
constraint and I would want to only  have the kernel tracer and not
bother with he userspace one.

[ltt-dev] UST communication library

[David Goulet]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Exactly! Thus having a hard dependency is completely out of question.

On 11-06-15 11:21 AM, Yannick Brosseau wrote:
> 
>> Enlighten me Yannick :)
>>
>> # apt-get install lttng-tools
>>
>> How are you going to have the UST support without installing the UST
>> package
>> (assuming that libustcomm is inside ust) ?
>>
>> I figure you'll have a "Not found libust.so..." at execution time ?
> 
> Exactly, for the *runtime* dependency, that would be a *recommand* and
> we detect if libusb is present or not. But  that's really up to the
> packager to decide how he does it. Each distro might have their own
> policies.
> 
> As the upstream developer, you should let the user decide if he want UST
> support or not. I might be building an embedded system were space is a
> constraint and I would want to only  have the kernel tracer and not
> bother with he userspace one.
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJN+M6aAAoJEELoaioR9I02y2AIALFkB/eEGG6V5of2dDPZ3NbL
MegoK0zV1rOh4XlMTuncdIfez7m21eore9FwkLvc2Lc6C0YpmbTmYnJgT52Ngz86
5L5YsHdpnYbkJ929UHwRZNByITmWRMJo71kI8+FAra5zw5EsVA5uRPJs6rvvsqlL
Xly+ldJsSUBE2B+1/dlx3oGugQ/3UqszPGdkFIml6HXZo1MnzlYljHg4r1x7a/eq
gjFGhlrqRuEC0orYrErK/F647Ng7WZmUcVGHp/5bThXWfKjUjymgNJFzz03YRixl
/us0FsZJr7n7Fz34AgJP7qEp/qcgcyGchcaI0seCYmr4yTbgnw1BvGuxzW6BTLg=
=zqFf
-----END PGP SIGNATURE-----

[ltt-dev] UST communication library

[Yannick Brosseau]

So the 1b)  options sounds good in this area.

On 2011-06-15 11:24, David Goulet wrote:
> Exactly! Thus having a hard dependency is completely out of question.
>
> On 11-06-15 11:21 AM, Yannick Brosseau wrote:
>
> >> Enlighten me Yannick :)
> >>
> >> # apt-get install lttng-tools
> >>
> >> How are you going to have the UST support without installing the UST
> >> package
> >> (assuming that libustcomm is inside ust) ?
> >>
> >> I figure you'll have a "Not found libust.so..." at execution time ?
>
> > Exactly, for the *runtime* dependency, that would be a *recommand* and
> > we detect if libusb is present or not. But  that's really up to the
> > packager to decide how he does it. Each distro might have their own
> > policies.
>
> > As the upstream developer, you should let the user decide if he want UST
> > support or not. I might be building an embedded system were space is a
> > constraint and I would want to only  have the kernel tracer and not
> > bother with he userspace one.
>
> > _______________________________________________
> > ltt-dev mailing list
> > ltt-dev at lists.casi.polymtl.ca
> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev

[ltt-dev] UST communication library

[Mathieu Desnoyers]

* Yannick Brosseau (yannick.brosseau at gmail.com) wrote:
> So the 1b)  options sounds good in this area.

1b (doing the libust .so detection at configure time) is much less clean
and flexible than the option I refered to in my previous email. 1b turns
into a static build-time detection what should really be dynamic
detection of compatible applications talking the same libust protocol,
based on a separate library with version number on the protocol.

Mathieu

> 
> On 2011-06-15 11:24, David Goulet wrote:
> > Exactly! Thus having a hard dependency is completely out of question.
> >
> > On 11-06-15 11:21 AM, Yannick Brosseau wrote:
> >
> > >> Enlighten me Yannick :)
> > >>
> > >> # apt-get install lttng-tools
> > >>
> > >> How are you going to have the UST support without installing the UST
> > >> package
> > >> (assuming that libustcomm is inside ust) ?
> > >>
> > >> I figure you'll have a "Not found libust.so..." at execution time ?
> >
> > > Exactly, for the *runtime* dependency, that would be a *recommand* and
> > > we detect if libusb is present or not. But  that's really up to the
> > > packager to decide how he does it. Each distro might have their own
> > > policies.
> >
> > > As the upstream developer, you should let the user decide if he want UST
> > > support or not. I might be building an embedded system were space is a
> > > constraint and I would want to only  have the kernel tracer and not
> > > bother with he userspace one.
> >
> > > _______________________________________________
> > > ltt-dev mailing list
> > > ltt-dev at lists.casi.polymtl.ca
> > > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

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

[ltt-dev] UST communication library

[Alexandre Montplaisir]

On 11-06-15 11:16 AM, David Goulet wrote:
> On 11-06-15 11:01 AM, Yannick Brosseau wrote:
>>>>> 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...
>> No, this is not problematic. When we create a package, we just have to
>> build-depend on UST. That way, people who wants to build it by hand
>> without UST, don't need to install UST.
>> Also, for distro like gentoo, you can build your package with UST support.
>>
> Enlighten me Yannick :)
>
> # apt-get install lttng-tools
>
> How are you going to have the UST support without installing the UST package
> (assuming that libustcomm is inside ust) ?

The optional dependency would be at compile time (during the configure). 
For distribution packages, it's up to the packager to decide which 
options to turn on/off. In this very case, it would make sense to turn 
it on, so the lttng-tools .deb (or .rpm, etc.) package would depend on 
the libust one. But at the "source package" level, the dependency would 
be optional.

This allows users with specific requirements (limited space, embedded 
targets,...) to compile/configure the way they see fit, but for generic 
users who just "apt-get install", they have all the options enabled.

This is exactly what happens with big configurable programs (mplayer, 
wine, etc.) where the source package has all the knobs and it's up to 
the distribution packaging to provide a sane set of defaults.

>
> I figure you'll have a "Not found libust.so..." at execution time ?
>
> David
>
>> Yannick
>>
>>
-- 
Alexandre Montplaisir
DORSAL lab,
?cole Polytechnique de Montr?al

[ltt-dev] UST communication library

[Yannick Brosseau]

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.

Yannick

[ltt-dev] UST communication library

[David Goulet]

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

Thanks
David

> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJN+MwvAAoJEELoaioR9I02kEYIAKaPzG994seeNnb/MyZUYZfY
seH1g1Lgtzq2qTF0sglq9alwOfD1KnqvPPr+YtkkAKGaN1A+hHO1NxDsn9ZdBBgu
5upkbLuASGd5ZezdUvYSMzYDxyY1WJgUcT/1vkU1BBFaaEFq9rkWHh11LMgBaaIC
FkSy1xSm8WV/BiJ6IGjtiCcUoDeXxruKjp6rTUf9NYo+MMDTp8xf3BKNSmGSdK6S
zyrJBxDZZsbQHd/rcf/6xZtP6sHey0VoiQDB8PlcFA6kBjkMojdu6fPzXDkAAdv5
18kKbGdyY107aLr7KxtYp+9NIXfDGOpKKCu4HqSPmxQsJBgPx+sar/4eF3tD3Kg=
=99lw
-----END PGP SIGNATURE-----

[ltt-dev] UST communication library

[Yannick Brosseau]

On 2011-06-15 11:13, David Goulet wrote:
>
>
> 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.
With our architecture, there is not code duplication, because it's not a
generic bidirectional communication. Some message goes in our directions
and some other in the other.
The controller and the "provider" each use their own part of the library
(it there is  a library)

[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

[ltt-dev] UST communication library

[Yannick Brosseau]

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. ustcomm does not
exist outside of UST. Since it does not have a value on its own, It
should be part of UST. Changing an dependency from UST to ustcomm is not
removing any dependency, its just adding one more and it makes it harder
to maintain.

Yannick

[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

[ltt-dev] UST communication library

[Alexandre Montplaisir]

On 11-06-15 01:16 PM, Mathieu Desnoyers wrote:
> * Yannick Brosseau (yannick.brosseau at gmail.com) wrote:
>> 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.

I've been wondering, why is the lttng-tools -> libust dependency so "bad" ?

And what changes by moving to lttng-tools -> libustcomm ? That is still 
asking people to compile/install another library before installing 
lttng-tools.

> [...]
> 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.

libtool takes care of this. And even if they are part of the same source 
tarball / git tree, libust and libustcomm can each have their own 
libtool version number.

Obviously you decide ;)  but I agree with Yannick : if libustcomm does 
not provide any functionality of its own, it shouldn't be isolated. A 
case where it would make sense to have a separate library is if you want 
to export the "UST protocol" to other applications so they can use that 
protocol outside of libust and lttng-tools. This do not seem to be the 
case, at least for now.

>
> Thanks,
>
> Mathieu
>


-- 
Alexandre Montplaisir
DORSAL lab,
?cole Polytechnique de Montr?al