Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: jonathan.r.julien@gmail.com (Jonathan Rajotte)
Subject: [lttng-dev] Machine Interface
Date: Thu, 13 Feb 2014 14:16:59 -0500	[thread overview]
Message-ID: <20140213191658.GA16437@gmail.com> (raw)
In-Reply-To: <CAFXXi0mcn4MUA0iHE-+HGqcqrsyf=wgWXPFMnBJrc+xrF96gaQ@mail.gmail.com>

On Thu, Feb 13, 2014 at 01:26:09PM -0500, Simon Marchi wrote:
> It looks good!
> 
> Comments below.
> 
> On 13 February 2014 13:00, Olivier Cotte <olivier.cotte at polymtl.ca> wrote:
> > At first, we wanted thank you for your quick and constructive feedback!
> >
> > After reflection on the nature of the problem and consideration of your
> > feedback, we've arrived with the following solution.
> >
> > The technology that will be use is XML. The integration of the machine
> > interface to LTTng will be done in the most modular manner to facilitate the
> > support multiples outputs format. This option will most likely be available
> > at configure time.
> >
> > For the moment, we will focus our effort into adding the XML feature only.
> > If many outputs languages is still a viable feature, it will be possible to
> > investigate.
> >
> > Our main goal is of course to promote extensibility, ease of development for
> > new tools and establish a standards for the communication control flow. Here
> > are our primary requirement concerning the machine interface:
> >
> >   * Fit the tree structure of LTTng commands structures.
> >   * It can be parse from bash/shell script with no external helpers.
> >   * The new format must not introduce any dependencies to LTTng.
> >   * [Optional] Still human readable, but fit to be parse.This is not a
> >      priority since we are talking about a machine interface.
> >
> > Here are the reason why we think XML should be used for the machine
> > interface:
> >
> >   * The expression of LTTng hierarchy really fit a XML tree structure.
> >   * Since Jgalar add a load-save feature that depend on libxml2, we are
> >     not introducing any dependencies. Choosing another format would
> >     most likely introduce new dependency.
> >   * XML is robust and easily extensible. It will also be easy to
> >     maintains (add new commands, modify existing commands etc.)
> >   * There are tools that allow you to evaluate XPath expressions from
> >     the bash.
> 
> In the requirements above, you said "It can be parse from bash/shell
> script with no external helpers". For XML it's not really the case. I
> don't really mind (I am fine withXML), but I just think those are
> contradictory statements.
True, but the requirement are 'ideal objectives'. The choice of XML do not complies with
this requirement but fits most of the requirements. I think we
misspoke on this.
> 
> >   * XML is an established standard
> >
> > That's why we consider XML format as a suitable solution.
> >
> > Now for the machine interface syntax:
> >
> >   * Since we are aware that multiple output could be supported, we want an
> >     unify flag for all machine interface command.
> > The flag --xml would be used to output xml from LTTng (we could add
> > similar
> > options like --json, --yaml etc.). This would be similar to svn
> > machine interface and speak for itself.
> >   * Also, to avoid confusion we will use a different primary command for
> > input and
> >     output machine interface.
> > Ex: lttng machine <input>
> > Ex: lttng --xml <output>
> 
> Can you give an (preliminary) example usage of lttng machine ? The XML
> document would be a big string / a single argument ?
> 
We are not sure yet... but probably a big string(one-lined XML).
Could be a file but i don't see any advantage.

Another option would be a prompt.. like GDB Machine Interface.
> Also, could lttng machine also be able to read its input from stdin?
> If it does, could it receive multiple commands in a single invocation?
> For example, each root-level XML element could represent a command.
> This way, a program would have to do a single exec and then push all
> the commands one by one to the lttng client.
> 
That was the plan.

To be frank, we will mostly put effort in the output side of MI.If
everything is *functional* and *approved* we will work on input.

> I have not really thought this through, I am just putting the idea in the wild.
> 
> > Any points we are missing?
> 
> I don't know how it would look, but as a user/developer, it would be
> nice if there was a way for lttng to dump me the XML that corresponds
> to a command (e.g. what I need to feed lttng machine to have the same
> effect as a command).
> 
> Example with syntax I just made up:
> 
> lttng --dump-xml-input enable-event -k sched_switch,other_event
> 
> would output
> 
> <lttng>
>     <command name="enable-event" domain="kernel">
>         <event name="sched_switch"/>
>         <event name="other_event"/>
>     </command>
> </lttng>
> 
nice idea

> I feel that this feature would make the machine interface more
> approachable (less doc to read before you start being efficient). What
> do you think?
> 
> Simon
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Jonathan Rajotte Julien
Charg? de laboratoire INF1995
Membre MD6
Polytechnique Montr?al



  reply	other threads:[~2014-02-13 19:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-13 18:00 Olivier Cotte
2014-02-13 18:26 ` Simon Marchi
2014-02-13 19:16   ` Jonathan Rajotte [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-02-13 20:05 Thibault, Daniel
2014-02-13 20:36 ` Jonathan Rajotte
2014-02-13 20:41   ` Thibault, Daniel
2014-02-06 13:51 Thibault, Daniel
2014-02-06  2:42 Jonathan Rajotte
2014-02-06  7:41 ` Woegerer, Paul
2014-02-06 13:32   ` Simon Marchi
2014-02-06 17:07     ` Woegerer, Paul
2014-02-06 18:40       ` Simon Marchi
2014-02-06 16:11 ` Christian Babeux
2014-02-06 17:00   ` Jonathan Rajotte
2014-02-06 18:21     ` Christian Babeux

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=20140213191658.GA16437@gmail.com \
    --to=jonathan.r.julien@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