global tracing

[Roland McGrath]

> The alternative I considered is the nonexistence of global tracing
> support, thus no utrace_global_flags test in the syscall fast path.

It will never be in the fast path.  It will always require
TIF_SYSCALL_TRACE to bet set on each thread, which means the slow path.
In comparison, one or two more or fewer loads is negligible.

> Well, it would be desirable to have some facility to block/resume and
> send signals to threads.  It would be desirable for this not to be
> available only for utrace-probes and not only targeting the currently
> utrace-hooked thread, but enqueue the command to an arbitrary one.

"Sending signals" if you just mean in the generic sense is already
available independent of anything else (send_sig et al).  That is just like
a tkill syscall, but done in a kernel module.  If that's all you mean, then
it's just a one-off injection (queuing) call and doesn't need to tie into
anything else at all.

When you make "enqueue the command" concrete, what it means is to attach a
utrace engine to do the control of the thread you want.  It's your business
when and where you decide to do this, but that's what you'll be doing.


Thanks,
Roland