Il mar 1 apr 2025, 10:27 Daniel P. Berrangé <berra...@redhat.com> ha scritto:
> This is a non-trivial degradation for the tracing code. The code is > generated in an inline function in the header so that when a probe > point is not active, it has as little overhead as possible - with > some backends it will just a 'nop' instruction. With this change > every probe is turned into a function call with no possiblity to > optimize away this overhead. > > IMHO tracing in Rust needs to be done by generating native Rust > code for the (sub)set of trace backends that we care about, and > not attempt to wrap the C trace code from Rust. > A little bit of both. Moving the body of the tracing to a C out-of-line function is okay: easier than converting printf strings to Rust format strings and possibly *more* efficient. The condition must remain inline though. Also, the focus should be on what the Rust API should look like, not on throwing some code on the other side of the fence. Introducing a second language has the risk of introducing massive technical debt, and therefore requires some design work. Tracing and logging is certainly not a one-patch task. Paolo With regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- > https://www.instagram.com/dberrange :| > > >
