i'm not sure using numbers rather than strings is a good idea, given
that Javascript's stupid "everything's a double" belief leaked into
JSON (and from there into JSON parsers). that's fine for int32_t but
not int64_t.
On Thu, Mar 13, 2014 at 2:02 AM, Mike Frysinger <vap...@gentoo.org> wrote:
> On Tue 11 Mar 2014 15:10:12 Philippe Ombredanne wrote:
>> On Tue, Mar 11, 2014 at 12:44 PM, Mike Frysinger wrote:
>> > the format will need some way of marking suspended/resumed calls
>>
>> This would apply only when you follow processes with -f right? -ff has
>> no unfinished/resumed business.
>> So we could limit support for a structured output to a -ff output only?
>> Or would this be too much of a limitation?
>
> fundamentally, strace sees two events -- entering and exiting. the fact that
> it appears as one call is merely because nothing happened inbetween and
> because it was fast. it would probably be a bad limitation if we only
> delivered "whole" results. especially if someone wanted to write a GUI that
> used strace as the backend ... when the app hit a sleep() or other long lived
> call, they wouldn't see the entry at all until it finished.
>
> also consider that the inputs/outputs could be spread across args. to see
> what i mean, run:
> strace sleep 2
>
> see how the syscall & first arg are decoded & displayed, then the system
> pauses. after 2 seconds, the 2nd arg and the return value are decoded &
> displayed. so we probably need to also support delivering info about
> inputs/outputs and intermingling them.
> {
> "syscall": "nanosleep",
> "state": "start",
> "arg0": {
> "dir": "in",
> "raw": "0x12345",
> "cook": "{1, 0}",
> },
> }
> ...
> {
> "syscall": "nanosleep"
> "state": "finish",
> "arg1": {
> "dir": "out",
> "raw": "0x6789",
> "cook": "{0, 0}",
> },
> "ret": "0",
> }
>
> that'd probably be fine for a first cut. longer term, we'd probably want to
> consider delivering the results broken out even more:
> "bake": {
> "tv_sec": "1",
> "tv_nsec": "0",
> }
>
> and instead of packing everything as strings, actually deliver them as
> numbers:
> "bake": {
> "tv_sec": 1,
> "tv_nsec": 0,
> }
>
> we'd probably have a number of extended options for controlling the output
> like dumping the syscall table so people can ingest it easily for GUI
> creation.
>
>> > and making
>> > sure the other side is able to sanely re-assemble them. and do so across
>> > processes/threads/signals/etc... :).
>>
>> Note that with -f, reconciliation of unfinished to resumed calls can
>> be based on the PID and a stack of unfinished calls and afaik there
>> should be no ambiguous case of a resumed call that cannot be traced to
>> its unfinished call correctly this way.
>> So IMHO even if we support a -f structured output there is nothing
>> super special to support reassembling these sanely as long as the
>> structured output has the pid, as it should.
>> We should just make sure that we provide some extra field that states
>> a call is unfinished or resumed.
>
> that probably should be sufficient since i think that's how strace is
> operating internally already
>
>> Sidebar: how to handle structured PIDs with -ff vs. -f:
>> - in -ff today, the trace does not contain the PID, only the trace
>> filename holds the PID.
>> - with -f the trace contains the PID on each line.
>>
>> I think we should err on dealing with PIDs in a uniform way with -f or
>> -ff and always have a pid field in these cases, even if there might be
>
> sounds fine
>
>> Other suspension cases could be things that happen after some signal
>> interruptions (even in a -ff trace) such as:
>>
>> nanosleep({15, 0}, NULL) = ? ERESTART_RESTARTBLOCK
>> (Interrupted by signal)
>> --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=3948067, si_uid=1000}
>> --- restart_syscall(<... resuming interrupted call ...>) = 0
>
> this isn't specific to -f or -ff. you'll always see this behavior.
> strace sleep 1000
>
> now in a diff term, do:
> kill -STOP `pidof sleep`
> kill -CONT `pidof sleep`
>
> further consider what happens if you have a custom signal handler that makes
> syscalls. when it returns, the original syscall will be resumed. or if you
> have nested signals.
>
> this is another reason why a flat array won't really work ... strace also
> needs to pass along event information that aren't syscall related like
> signals.
>
>> - always include a pid field in the structured output of -f and -ff
>> - add a field to support unfinished/resumed business with -f. This
>> could be something like a "state" field with possible values of empty,
>> unfinished or resumed
>
> i think it'd go even deeper. every syscall (independent of -f/-ff) would have
> a state field.
> state: {start, resume, finish}
>
>> A stylistic question would be:
>> should fields be always included even if empty in the case of pid or
>> state? or should they be only present if asked for?
>> aka sparse vs. dense output? I would tend to prefer sparse without
>> empty values than dense with empty values a dense output with empty
>> values would still require a parser to test for empties. sparse values
>> would require to test for presence, so in both case the parser would
>> have to test something.
>
> sparse should be fine. any sane JSON parser can deal with this easily.
> -mike
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Strace-devel mailing list
> Strace-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/strace-devel
>
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Java i18n/JNI/NIO, or bionic questions? Mail me/drop by/add me as a reviewer.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
