From mboxrd@z Thu Jan 1 00:00:00 1970 From: simon.marchi@polymtl.ca (Simon Marchi) Date: Thu, 6 Feb 2014 08:32:20 -0500 Subject: [lttng-dev] Machine Interface In-Reply-To: <52F33CBA.5000802@mentor.com> References: <20140206024218.GD23121@gmail.com> <52F33CBA.5000802@mentor.com> Message-ID: On 6 February 2014 02:41, Woegerer, Paul wrote: > On 02/06/2014 03:42 AM, Jonathan Rajotte wrote: >> Hello all, >> >> After speaking with Michel Dagenais, Genevi?ve Bastien, folks over at EfficiOs >> and Ericsson, a machine interface for lttng-tool would be a nice feature >> to have. Olivier Cotte and me will be working on MI for the >> next few weeks. >> >> The main objective would be to reduce parsing complexity >> in control tools. >> ex:Regex used in TMF control service. >> (org.eclipse.linuxtools.internal.lttng2.ui.views.control.service.LTTngControlService.java) >> >> Multiples solutions come to mind: >> -XML >> -JSON >> -YAML > > YAML sounds very attractive in this context. I am also fond of the yaml syntax. It is very easy to read/write by a human. Not sure how much this matters though, since is a machine interface. > It's easily parseable even from a shell script. If you need to automate > LTTng tracing tasks on a small embedded target busybox is all you have! This point is relevant for me, since I actually intend to use this to enhance bash completion, which is done with a bash script. I never thought I would say that one day, but I think that XML could have an advantage here. Parsing yaml with regexp (such as in a shell script) is easier than XML, but it's still not bulletproof. Consider this eventual yaml structure I just made up for the output of the session list. sessions: - name: my_session domain: kernel events: - name: sched_switch filter: prev_pid == 1234 - name: sched_migrate_task otherproperty: "something" - name: another_session domain: ust events: - name: event_hello - name: event_bonjour loglevel: 3 If you want to get the list of sessions, you'll probably want to grep the "name: " entries, but then event names would match as well. Of course, names could be different, or you could grep for the appropriate amount of spaces/tabs at the beginning of the line. But then it also depends if the name dictionary entry is the first, then it will have a "-" in front... It's possible, but it will also be very easy to break scripts. With XML, there are tools (xmlstarlet, xmllint, probably others) that allow you to evaluate XPath expressions and thus not depend of the formatting. For example, an equivalent XML schema could be To get a plain list of sessions, you could then do $ lttng list --mi | xmlstarlet sel -T -t -v "/lttng/session/@name" -n my_session another_session Maybe such tools exist for yaml? Also, I understand your point for embedded devices though, where space is limited and you don't want to load an XML lib/tool just for that. If the design of the MI is somewhat modular though, it could be possible to support more than one output format, with the different options available at configure time. > Best, > Paul > >> -Custom syntax (like GDB Machine interface* as proposed by Alexandre >> Montplaisir) I would suggest not going for a custom syntax... that sounds like more work for more chances of bugs. >> XML/JSON/YAML promote extensibility and ease of development for new tools >> dependant on lttng-tools by being established standards. >> On the other hand, they add dependencies to lttng-tools where a custom syntax >> would not. I would suggest making the dependency optional. If you don't have the lib, or don't want to depend on the lib, have a --disable-something at configure time. >> Machine interface output would be generated only with --mi option and >> could contain additional information than regular output. >> >> We are focusing on output right now but we may eventually add a 'mi' >> command for input if necessary. >> >> What do you think ? >> >> Thanks >> >> >> *https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html >> > > > -- > Paul Woegerer, SW Development Engineer > Sourcery Analyzer > Mentor Graphics, Embedded Software Division > > > _______________________________________________ > lttng-dev mailing list > lttng-dev at lists.lttng.org > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev