On Tue, Mar 11, 2014 at 12:44 PM, Mike Frysinger <vap...@gentoo.org> 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?
> 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.
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
also a pid in the output filename.
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
I am not sure this (-ff) output above would warrant any special
treatment, since this is a different animal and not an
unfinished/suspend proper IMHO.
In the case of a -f output you could turn out as also having the
restart_syscall itself unfinished this would be a regular
unfinished/resume processing IMHO:
3948469 restart_syscall(<... resuming interrupted call ...> <unfinished ...>
3948468 wait4(-1, <unfinished ...>
3948466 --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER,
si_pid=3948067, si_uid=1000} ---
3948466 wait4(-1, <unfinished ...>
3948469 <... restart_syscall resumed> ) = 0
So to recap I suggest:
- 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
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.
--
Philippe Ombredanne
------------------------------------------------------------------------------
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
