Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: yannick.brosseau@gmail.com (Yannick Brosseau)
Subject: [ltt-dev] UST communication library
Date: Wed, 15 Jun 2011 11:01:34 -0400	[thread overview]
Message-ID: <4DF8C94E.9090104@gmail.com> (raw)
In-Reply-To: <4DF8C859.40904@polymtl.ca>

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




  reply	other threads:[~2011-06-15 15:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-14 21:26 David Goulet
2011-06-15  5:23 ` Alexandre Montplaisir
2011-06-15  8:09   ` Nils Carlson
2011-06-15 14:57   ` David Goulet
2011-06-15 15:01     ` Yannick Brosseau [this message]
2011-06-15 15:16       ` David Goulet
2011-06-15 15:21         ` Yannick Brosseau
2011-06-15 15:24           ` David Goulet
2011-06-15 15:26             ` Yannick Brosseau
2011-06-15 15:41               ` Mathieu Desnoyers
2011-06-15 18:51         ` Alexandre Montplaisir
2011-06-15 15:06 ` Yannick Brosseau
2011-06-15 15:13   ` David Goulet
2011-06-15 15:16     ` Yannick Brosseau
2011-06-15 15:32     ` Mathieu Desnoyers
     [not found]     ` <BLU0-SMTP5372DAF7E219ACFC9DE44C966B0@phx.gbl>
2011-06-15 15:55       ` Yannick Brosseau
2011-06-15 17:16         ` Mathieu Desnoyers
2011-06-15 19:11           ` Alexandre Montplaisir

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DF8C94E.9090104@gmail.com \
    --to=yannick.brosseau@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox