Fwd: GSOC 2015 : Structured Output

[Dmitry V. Levin]

Hi,

On Wed, Apr 15, 2015 at 12:46:32AM +0530, Amish Mittal wrote:
>     i grep the code of strace 4.10 in and out for this project. This is
> what all i got for this project:
> we don't need to change the tprintf and tprints calls, we only need to
> slightly change their definition.
> My idea for this project:
> 1) crate one global char buffer in strace.c
> 2) if json flag is set then tprintf and tprints will not print write
> anything in current_tcp->outf , they will just write the whole string in
> our char buffer
> 3) one JsonFormatter which converts and writes our string in json format
> 
> example :
> JsonFormatter(execve( current_tcp->outf   ,"\"./a.out", ["./a.out"], [/* 80
> vars */]) = 0" , sizeOfBuffer)
> 
> will write
> {
>   "Function" : execve
>   "Arguments" : ("./a.out", ["./a.out"], [/* 80 vars */])
>   "Return" : 0
> }

What you are essentially proposing is to parse strace output for the
second time in hope that this traditional C-style human readable output
would be regular enough to produce a reliable structured output.
If this hypothesis was true, there would be no need to add this converter
into strace itself.

The problem is that traditional strace output is not 100% regular, and
the idea as I understand it is to change strace to parse all syscalls,
signals, etc. into a structured internal representation that would then
be printed either in traditional C-style format or in a structured format.


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