[GSOC2015] JSON Formatting

[Dmitry V. Levin]

On Sat, Mar 07, 2015 at 06:33:45PM +0100, Louis Feuvrier wrote:
> On Sat, Mar 07, 2015 at 05:38:40AM +0300, Dmitry V. Levin wrote:
[...]
> > Yes, but please keep in mind that not all syscalls are that simple.  For
> > example, many syscalls have some of their arguments decoded on exiting
> > syscall, and some syscall arguments are decoded both on entering and
> > exiting syscall, e.g. _IOWR ioctls.
> 
> I understand fully that this is the base case scenario. However, I don't
> understand something regarding the arguments being printed after the end
> of the syscall. Are they printed out twice? I looked a bit at the code
> path for _IOWR ioctls and I don't see when it is done. The sys_ioctl
> function looks like it is called at the same time as all the other sys_
> functions.

$ git grep 'tprint.* [=-]> '

> > I think a per-tcb output state machine with its own stack (remember about
> > nested objects) is the right approach.
> 
> A recursive approach

It doesn't have to be a recursive approach.  The stack is needed to decide
whether the given object is the first element of array/struct/list.  Also,
it could be useful in automatic detection of errors in parsers, e.g.
an unfinished array/struct, objects that begin as an array and end
as a struct, etc.

> to nested-objects would imply a subroutine for each
> type of argument, am I right? Would this be the right approach?

We would need a subroutine for each basic json type, e.g.
string, number, pair, array, struct.

> I feel
> like it is too great of a change and shifts a great deal of logic into
> the outputting module.

The only noticeable shift of logic I see is the business of tracking and
printing delimiters.


-- 
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/20150308/2c54cadf/attachment.bin>