> > 2. Why do we want utrace global tracing?
>
> From a systemtap point of view, we'd certainly use global tracing.
You're using tracepoints/markers too. (You'll use anything, you minx.)
What we need is reasons for this to be a utrace feature.
> Global tracing would be *really* nice; your reasons sound *great*.
> How's that? :-)
Cursing me with loud praise!
> Seriously, your reasons a. ("Event vocabulary clearly aligned with
> utrace events"), b. ("Coordinated with per-task utrace callbacks"), and
> d. ("Kernel already has checks here, so "almost free") apply most
> clearly to systemtap. Systemtap doesn't currently change outcomes in a
> callback, so reason c. doesn't apply much. Systemtap is interested in
> performance impacts and the a./b. advantages seem quite obvious to me.
Ok. Since a. is basically aesthetic, I think what would be concrete here
is to see how you'd use it in practice such that b. matters to you.
> Avoiding the complexities of manually attaching/detaching to every
> thread in the system seems important also.
That's a reason to have some kind of global tracing as opposed to none.
Sold. It's not a reason to have utrace global tracing instead of only
tracepoints and markers.
Thanks,
Roland
