qemu-rust.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: saman <saman@enumclass.cc>, qemu-devel <qemu-devel@nongnu.org>,
	 Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-rust@nongnu.org, Mads Ynddal <mads@ynddal.dk>,
	 Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Subject: Re: [PATCH] Rust: Add tracing and logging support for Rust code
Date: Tue, 1 Apr 2025 10:39:31 +0200	[thread overview]
Message-ID: <CABgObfYNWPfeh67etsjaqeCf-5WvRqiAo3+czPpu37_=3buq-w@mail.gmail.com> (raw)
In-Reply-To: <Z-ujXI126OC9lZpi@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

Il mar 1 apr 2025, 10:27 Daniel P. Berrangé <berrange@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 :|
>
>
>

[-- Attachment #2: Type: text/html, Size: 2750 bytes --]

  reply	other threads:[~2025-04-01  8:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-01  0:26 [PATCH] Rust: Add tracing and logging support for Rust code saman
2025-04-01  8:27 ` Daniel P. Berrangé
2025-04-01  8:39   ` Paolo Bonzini [this message]
2025-04-01 19:21 ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABgObfYNWPfeh67etsjaqeCf-5WvRqiAo3+czPpu37_=3buq-w@mail.gmail.com' \
    --to=pbonzini@redhat.com \
    --cc=berrange@redhat.com \
    --cc=mads@ynddal.dk \
    --cc=manos.pitsidianakis@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-rust@nongnu.org \
    --cc=saman@enumclass.cc \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).