Tracing and monitoring is foremost about being able to trust the instrument,Not to mention that that process could wreck the trace data rendering itIt could, but it also might not. Are we going to deny high performance
tracing to users just because it doesn't work in all cases?
then about performance and usability. That's one of the big things about
ftrace and perf.
By proposing 'user space tracing' you are missing two big aspects:
- That self-contained, kernel-driven tracing can be replicated in user-space.
It cannot. Sharing and global state is much harder to maintain reliably,
but the bigger problem is that user-space can stomp on its own tracing
state and can make it unreliable. Tracing is often used to figure out bugs,
and tracers will be trusted less if they can stomp on themselves.
- That somehow it's much faster and that this edge matters. It isnt and it
doesnt matter. The few places that need very very fast tracing wont use any
of these facilities - it will use something specialized.
So you are creating a solution for special cases that dont need it, and you
are also ignoring prime qualities of a good tracing framework.