Hacker News Reader

Comment by brian_herman__ | Hacker News Reader

Shouldn’t it use eBPF on Linux instead of system tap?

This crate is for enabling low-overhead tracing of userland Rust code. To that end it supports both systemtap and ltt-ng.

Systemtap probes are available to eBPF instrumentation, so in that sense this does indirectly use eBPF. I know this isn't obvious, I haven't had a chance to get the docs up to my standard.

In fact I went to great lengths to ensure that the eBPF tracing tools can discover the trace points generated by this implementation. This even required submitting an upstream bug to the BCC toolchain. But now it works great for primitive types that have some meaningful equivalent in eBPF terms.

>Systemtap probes are available to eBPF instrumentation, so in that sense this does indirectly use eBPF. I know this isn't obvious, I haven't had a chance to get the docs up to my standard.

Sounds like a great use case to document.

Yes absolutely. Better docs are a top priority right now.

You can use eBPF tooling to attach to User SDT probes; this library is a way to instrument your code once and have those probes available via the appropriate tracing infrastructure on the running platform

Yes exactly. The goal of this project is to let authors put trace points in their code and at compile time target whatever tracing system makes sense. On Linux that's either systemtap or ltt-ng. On Windows it (will be; not implemented yet) the event tracing API, on MacOS and FreeBSD it would be dtrace. There's also an option to completely disable tracing at compile time, which removes all tracing code and imposes absolutely zero runtime overhead.

Worth noting that DTrace is now available on Windows too as of "recently" [1][2]. It would be great to support that also!

[1]: https://www.microsoft.com/en-us/download/details.aspx?id=580...

[2]: https://github.com/microsoft/DTrace-on-Windows

Cool! Assuming it's a faithful port with source-level compatibility, it should work with the existing DTrace implementation I'm building. The differences between compiler toolchains are already abstracted away by the excellent `cc` crate.

In any case I already have a Windows CI build; when DTrace is ready I'll add DTrace on Windows there and see what happens.

Great news, I'm very much looking forward to being able to use this crate! Thanks for your work (and that of those upstream of you).

Reply on news.ycombinator.com