From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Subject: [lttng-dev] UST app and lttng-tools compatibility
Date: Mon, 1 Oct 2012 11:24:35 -0400 [thread overview]
Message-ID: <20121001152435.GA13628@Krystal> (raw)
In-Reply-To: <20121001145619.GB13423@Krystal>
* Mathieu Desnoyers (mathieu.desnoyers at efficios.com) wrote:
> * Francis Giraldeau (francis.giraldeau at gmail.com) wrote:
[...]
> > Could the registration process block until the sessiond returns some
> > status?
>
> The session is not "returning" anything to the application. The
> application is registering to the sessiond, and all the sessiond can do
> is to keep the socket alive or close it.
>
> Even if we added a "command" that the sessiond could use to tell the
> application it has a wrong version, that would not be 2.0 material, and
> the application wouldn't know about it. Moreover, given we have changed
> the communication protocol, not sure we would like to have this extra
> command as entirely fixed for now, as it would be part of the
> communication protocol (which is not the case for the initial app
> registration, with is part of a lower level protocol).
>
> > I understand that in commercial setup, the application should
> > not be prevented to start and run normally if tracing is not available
> > or misconfigured.
>
> By default, we only block the application for up to 3 seconds at
> registration. I think that if we start the application with
> LTTNG_UST_REGISTER_TIMEOUT=-1, the application will, in this case, block
> forever (see man lttng-ust).
Let me take this last part back. That was a pre-morning-coffee
statement. ;) The application will receive a "registration done" message
when the version is found to be incompatible. Therefore, it will never
wait for the incompatible sessiond.
One thing we could do to make transition smoother between future
versions would be to add a new command to let the sessiond send its own
version info to the application. In this command's handler, the
application could show a warning on stderr. This could not apply to 2.0,
but we could do it starting from 2.1.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2012-10-01 15:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <50670C5A.4060800@gmail.com>
[not found] ` <20120929182800.GA19994@Krystal>
[not found] ` <5069111F.1080604@gmail.com>
2012-10-01 14:56 ` Mathieu Desnoyers
2012-10-01 15:06 ` David Goulet
2012-10-01 15:24 ` Mathieu Desnoyers [this message]
2012-10-01 15:27 ` David Goulet
2012-10-01 15:31 ` Mathieu Desnoyers
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=20121001152435.GA13628@Krystal \
--to=mathieu.desnoyers@efficios.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