This is a no-go, as Linux Kernel Markers history has shown. It's good for debug-style ad-hoc tracing, but having a declaration in a global header, like the tracepoints are doing, _really_ helps for tracepoint maintainability.
Having to dig into the C source to find buried trace_mark() instances is not a pretty picture.
I think keeping the trace_mark() infrastructure is good as far as quick local tracing addition is concerned, but should not be added to mainline kernel code, given it is hard to maintain.
And regarding the declaration complexity, it's added by the TRACE_EVENT() macros done by Steven. The original tracepoint flavor I did use DECLARE_TRACE, which is far simpler, e.g.
But it involves creating a probe module which contains the callback elsewhere. Adding tracer-specific callbacks in a different location is seen as too much of a burden by Ingo and Steven, hence their TRACE_EVENT() macro, which combines declaration and callback "definition".
I am still unconvinced it's the best way to go though, as keeping the callbacks separated from the header declaration isolates the "tracer ABI" from the kernel instrumentation. But given we stipulate that the tracer ABI *will* evolve over time (given we give the userspace tools enough flexibility to cope with this), it can be argued that having an "all in one place" TRACE_EVENT() declaration/definition is more valuable than isolation of instrumentation for userspace-visible ABI. I guess usage will tell.