strace: Qstrace controls whether tracing is on
authorBarret Rhoden <brho@cs.berkeley.edu>
Thu, 26 Jan 2017 17:14:42 +0000 (12:14 -0500)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 9 Feb 2017 17:31:08 +0000 (12:31 -0500)
commit2d0f3d2ae364e5017cb2d3b4fb584e3beedb9b33
treecec5313d1f1f1648f3d1064d065a06b62ebdb3e6
parent4275e10cc3493a5d8b7db073f574c2d6bc1c7f86
strace: Qstrace controls whether tracing is on

The ctl commands straceme and straceall set up tracing.  straceme turns off
inheritance; straceall turns it on.  The actual tracing only happens when
you open #proc/PID/strace (a.k.a. Qstrace).  There can be only one open
chan of this file.

Previously, there was a ctl message to turn off tracing, and tracing would
be turned on as soon as you sent the straceme ctl message.  There are a few
problems with this:

1) If the tracer exits or crashes, the tracee might continue to be traced.
If we start blocking the tracee when the queue is full, it'll just stop
forever.  This way, when the FD of the tracer is closed, tracing will stop.

2) If we want to filter syscalls, we'll want the strace struct to exist
first, and then later set the filter, and the later turn on tracing.

3) Having multiple readers is a mess.  Who knows who is getting the right
output?  That just seemed prone to bugs.

I had to move strace_on and strace_inherit back to the strace struct.  This
means that all processes sharing a struct strace (via inherit) are
controlled as a group.  The open FD for the struct strace is what controls
the tracing - you can't control it for individual processes.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/drivers/dev/proc.c
kern/include/env.h
kern/include/syscall.h
kern/src/syscall.c