On Tue, Aug 05, 2025 at 07:25:39PM +0300, Manos Pitsidianakis wrote: > On Tue, Aug 5, 2025 at 7:05 PM Daniel P. Berrangé <berra...@redhat.com> wrote: > > > > On Mon, Aug 04, 2025 at 04:47:13PM +0300, Manos Pitsidianakis wrote: > > > This RFC series contains some simple patches I've been sitting on for > > > some months to allow tracing in rust devices in a similar matter to C, > > > only it's done via a proc-macro codegen instead of using tracetool > > > script or equivalent. > > > > IIUC, this series is only emitting the traces events via the > > qemu_log function, and so feels like it is missing the benefit > > of tracing, vs the traditional logging framework. > > > > In our RHEL & Fedora distro builds we disable the log backend > > and enable dtrace, so that we have fully dynamic tracing and > > observability across the kernel, qemu, libvirt and other > > components with dtrace integration. > > Hi Daniel, > > Thanks for the insight! Do you have any points where I should look at > the trace implementation for how the different backends are supported? > > So I think there's already work in progress to support proper tracing > for Rust, I only sent this as a temporary fixup to provide some kind > of parity between C and Rust implementations until a proper, better > solution is available that can replace it.
Can the rust code not easily consume the existing functions in the trace.h files generated for the C code as a short-term solution ? It would not benefit from the code inlining in the same way as C would, but it would at least give feature parity for tracing with all the trace backends are available. Then, we can look at optimizing with a pure rust impl of some backends at a later date, to regain what we lost from lack of inlining ? 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 :|
