With #26593 merged, a few ideas for the Bitcoin Core tracepoint interface that could be next steps. I posted these as a comment in #26593 (comment) but surfacing them here for more visibility.

These ideas are all up for discussion and aren't TODOs. The numbers don't indicate order or priority but make it easier reference them.

Dependencies

1. • We could internalize the relevant macro parts of systemtap's sys/sdt.h for the Linux tracepoints. This would allow us to drop the external dependency on systemtap, as we don't use 99% of it. Some prior commentary on this can be found here: cmake: Switch from tri-state options to boolean. Stage TWO hebasto/bitcoin#162 (comment)

MacOS & FreeBSD support

2. • In the past I've managed to use a simple macro build a bitcoind with tracepoints on macOS. While our ebpf based demo scripts aren't compatible, @kouloumos DTrace scripts from tracing: macOS USDT support #25541 are. This could look similar to https://github.com/0xB10C/bitcoin/blob/13b0ce221600fc7040502c834c51433ca96f91c3/src/util/trace.h#L35-L63. However, I currently don't have access to a macOS system to further work on this - I'm looking to rent one.
3. • The same could possible on FreeBSD with e.g. these macros https://github.com/0xB10C/bitcoin/blob/13b0ce221600fc7040502c834c51433ca96f91c3/src/util/trace.h#L104-L119. I haven't tested this on FreeBSD yet. In build: Detect USDT the same way how it is used in the code #27458 (review), vasild mentiones he'd interested in FreeBSD tracepoints. My understanding is that the same macOS DTrace scripts from 25541 would work there too.
4. • At least for macOS, we'd need an per-tracepoint interface definition similar to https://github.com/0xB10C/bitcoin/blob/13b0ce221600fc7040502c834c51433ca96f91c3/src/util/trace.h#L121-L236. With some more commentary, these could replace the list of tracepoints in https://github.com/bitcoin/bitcoin/blob/master/doc/tracing.md#tracepoint-documentation. This would solve something similar to tracing: explicitly cast block_connected duration to nanoseconds #29877 (comment).

Interface stabillity improvements

5. • Even if we don't do 4. (because we e.g. don't want to do 2.), casting the tracepoint arguments to the type we expect to pass would be worthwhile to avoid problems like tracing: explicitly cast block_connected duration to nanoseconds #29877. For some of our traceponts, we already do this: e.g.

     bitcoin/src/validation.cpp

     Lines 2902 to 2907 in 900b172

     	TRACEPOINT(utxocache, flush,
     	int64_t{Ticks<std::chrono::microseconds>(SteadyClock::now() - nNow)},
     	(uint32_t)mode,
     	(uint64_t)coins_count,
     	(uint64_t)coins_mem_usage,
     	(bool)fFlushForPrune);

Example scripts

6. • We could drop the example scripts from /contrib/tracing/* and maintain them, along with proper tests in a CI, Bitcoin Core version compatibility information, possibly libbpf-based C or Rust tools (Porting bcc tools to libbpf #30298), ... in an external repository like, for example, 0xb10c/tracing-scripts, bitcoin-core/tracing-scripts, or bitcoin-monitoring/tracing-scripts (what ever would works best).

Maintain tracepoint interface, drop tracepoint implemenation

7. • If we at some point decide that maintaining the tracepoints in Bitcoin Core adds too much maintenance burden compared to the actual usage they're getting, we could drop the tracepoints but keep the tracepoint interface. We now have a unit test that includes a few nop tracepoints to check that the interface will still compile (https://github.com/0xB10C/bitcoin/blob/0de3e96e333090548a43e5e870c4cb8941d6baf1/src/test/util_trace_tests.cpp). This would allow us to drop the bcc python dependency in the CI and to remove the interface_usdt_* functional tests (which need to run in VM and can't run in a container). Tracepoint users could maintain a patch on Bitcoin Core adding the tracepoints (and tests) they want back in. We'd however loose the tracepoints in release (or actually all) builds which currently allow e.g. everyone experiencing problems with their node to hook into them and extract data without needing to restart it.