Structured output?

[Dmitry V. Levin]

On Thu, Feb 06, 2014 at 03:41:54PM +0100, Philippe Ombredanne wrote:
> On Wed, Feb 5, 2014 at 12:43 AM, Dmitry V. Levin <ldv at altlinux.org> wrote:
[...]
> > strace output format resembles C syntax.
> > And yes, it's so old that it probably predates html. :)
> 
> It does predate Linux too, right?  Your post says it all:
> http://lvee.org/en/abstracts/94 I guess, though it would be fun to
> know if Paul Krankerbug started strace before Linus started Linux in
> 1991.

Rick Sladkey wrote that the original strace was written by Paul Kranenburg
for SunOS and Paul's strace 1.5 release from 1991 was ported to Linux by
Branko Lankester.  If these statements are correct, then yes, it predates
Linux too. :)

[...]
> At a high level, the API may look something like this:
> - first regardless of the output format we decide on, the line-by-line
> approach makes the most sense. e.g. output would still be one physical
> line per syscall or +++ message
> 
> - then the key elements of call are time, pid, function name, return
> code, decoded return code, extra return info and of course arguments.

Notification messages may need more elements.
At this moment we have 3 types of +++ messages (exited, killed,
superseded) and 2 types of --- messages (siginfo and stopped).

There is an ioctl parser "or" feature that should be dealt with:
ioctl(2, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0

Also, there are such things as "unfinished" and "resumed" markers.
They break traditional C-style output format, so mapping them
to a well-structured format is not going to be trivial.

> - for arguments this is a list positional value or key/value map where
> the value can be a list or map of further decoded structures.
> 
> - there is a duality of raw vs. decoded args, such as for file
> descriptor-like where you have a tuple of (fd, decoded path), so it
> could make sense to provide both the raw and decoded value as a tuple
> for many arguments
> 
> - whatever the api used, it should be able to print the exact same
> format as today pixel per pixel ;)  and support ideally only one new
> structured format for now.
> 
> - I have no special preference for a format, except that I prefer text
> over binary and that this should be a standard well-defined format with
> plenty of available support in most languages. Of text formats, using
> some CSV-like would still be flat (short of inventing a non-standard way
> of nesting data) and would likely be a regression from the current
> format; XML is likely too verbose; yaml structure requires multiple
> lines; Json is a tad verbose but less so than XML and a list entry can
> be packed on a single line. So a json-like format is likely a good
> candidate but this is not really super friendly for piped input
> processing with common shell tools (though the current strace output is
> more or less there for that today).

Agreed.

> So we could have a single or few print function replacing tprintf and
> tprints that could accommodate receiving some structures and formatting
> code as used today, and a flag to output regular strace or a structured
> strace?

That's less obvious.

> Something along these lines...
> 
> As a first step I think the best would be to come with a few mock
> samples of json output.  -- Philippe Ombredanne

I wonder how printxval and printflags would look like.
For example, what would be a json-like equivalent for this traditional output:

$ printf '#include <sys/socket.h>\nint main(){return socket(AF_INET,-1,0xffff)<0;}' |gcc -Wall -xc -
$ strace -esocket ./a.out 
socket(PF_INET, SOCK_CLOEXEC|SOCK_NONBLOCK|0xfff7f7ff, 0xffff /* IPPROTO_??? */) = -1 EINVAL (Invalid argument)
+++ exited with 1 +++


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20140207/40641d25/attachment.bin>