It looks good! Comments below.
On 13 February 2014 13:00, Olivier Cotte <[email protected]> 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. > * 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 ? 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. 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> 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 [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
