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
next prev parent 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