Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Subject: [lttng-dev] UST app and lttng-tools compatibility
Date: Mon, 1 Oct 2012 11:31:59 -0400	[thread overview]
Message-ID: <20121001153159.GB13944@Krystal> (raw)
In-Reply-To: <5069B658.8010106@efficios.com>

* David Goulet (dgoulet at efficios.com) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> 
> 
> Mathieu Desnoyers:
> > * 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 ?
> 
> Why sending version infos instead of a "incompatible" command ?

It could very well be an "incompatible" command, but it would need to
contain the version info, so the application can print the versions.

The main difference between sending version info (all the time) and the
"incompatible" command is that the version info would be sent all the
time. It could provide better debugging logs in the app when using
LTTNG_UST_DEBUG=1, but would require one extra message at app
registration. Not sure which is best.

Thoughts ?

Thanks,

Mathieu

> 
> David
> 
> > 
> > Thanks,
> > 
> > Mathieu
> > 
> > 
> -----BEGIN PGP SIGNATURE-----
> 
> iQEcBAEBCgAGBQJQabZVAAoJEELoaioR9I02RYcIALJ7ySGiU6nKDD4F4ffAEIFr
> ZSQC/1mhr8x66TfTdB9eGaAxA6qmESEBpg6bjyWSmWCn1dI1i5lOeXhxszM1Z8Oz
> q6DKSSlRVRZFrCaZBf3Xy7QNbxTdUkwrcCjd8Y9Ffu1BswXIzzUhsYSHbJRQAHVF
> QAuNFy5AeHRlE55H94Gs/ydfiQb3jqVIalVnG5LmeDPyO58sdA+RAWkwaJypgL8e
> 5m6r3K0IK5ufSIjWWb6G8vmf3HFV3zzdEwGpkEyaVRZjUfDBekRnJ27Bb2XqJUxC
> /xe2S519VLnsCWE+j1pfN5BcchI0TKUOeTcaLzzaf/VdkHdlOmZlifSZ6ubRusU=
> =OVEY
> -----END PGP SIGNATURE-----

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



      reply	other threads:[~2012-10-01 15:31 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
2012-10-01 15:27         ` David Goulet
2012-10-01 15:31           ` Mathieu Desnoyers [this message]

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=20121001153159.GB13944@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