From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1tzX9z-0005wU-Ox for mharc-qemu-rust@gnu.org; Tue, 01 Apr 2025 04:39:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tzX9x-0005vo-Hc for qemu-rust@nongnu.org; Tue, 01 Apr 2025 04:39:49 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tzX9v-0001jm-O1 for qemu-rust@nongnu.org; Tue, 01 Apr 2025 04:39:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1743496785; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=R5CUnTw7XaT5k94huOQtQ6egMWSK52jbJtE05Bw6TMg=; b=h876r+klp9NPwBsgOyWFOPS0Bizk+XMQ20ghtbzzL/yDCekMpWx3ii/4LU3x8WOkeihXUe FEjjC1yKdU8iZl7yCv1Vr972TOSqR9NYstFdbZUnPlrROsn8DEfFpRgN/j+MLFMsC/8wvN r+1+kNPJlLfT2ZdE5Myk8GH3YIShR1U= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-54-KTI4-YZMOOSvuU0a1f_B_Q-1; Tue, 01 Apr 2025 04:39:43 -0400 X-MC-Unique: KTI4-YZMOOSvuU0a1f_B_Q-1 X-Mimecast-MFC-AGG-ID: KTI4-YZMOOSvuU0a1f_B_Q_1743496783 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-43d51bd9b45so34086285e9.1 for ; Tue, 01 Apr 2025 01:39:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743496782; x=1744101582; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R5CUnTw7XaT5k94huOQtQ6egMWSK52jbJtE05Bw6TMg=; b=G32Zy44ahyyyYQ4PVdEHF/YBI+y11YdApyArfK0dgnZXKX/UCWJEfnnCl2sSzdzDF+ BGms1x+uz3aQK0FIhp8jeNOIDa5ljbUXPV8t3l4KvV4kmwKBqXzjpIZqMtqQuUHjmyZO 7bcO5TDw+LjkBOYuO52cjbYA27eV+VfbylcUrk5+lS0H3Yrsi/4TCdJVjDaFVljUfNaf HZasy4calpTDYCiu26vm7/S5ei5/wOztxbfRbtMu+ZfIO+PdgdfSmObfQYkjiBIotRBa 038ruPik/Jhqa/7ddkdHx4bFhBFQVYXBfWMYqKW7F3kS7ghJgGYhoe1xdl7v9MfISQiJ FToQ== X-Forwarded-Encrypted: i=1; AJvYcCVhIfmk5+vANo+DrK/7KKqwoLiwTo+dqqKXXBKQP8Pbha8QrdViTCTmkU9Ef96T2uCgYBllcAmIzu8=@nongnu.org X-Gm-Message-State: AOJu0Yz7AdFB5daVRw7zZbuHB3WduhoyqZYHWZII6rm8vGmyqLmHJjt9 PNfZfDZNkRcF2yusobvvrlBODZVYkjNPmh04ccy3K+wPfusfuVD4Xujv8wqa0QeNIv+wp59EdhL BTINtas6sF6Q5hXbCG3Ohg3Y0fq9dukR27k6eHaq7sdR3dLZ5aI9p7RJKywHGks7XZRubP4BIIS B6F2cxnhW+imTtjXJMb2XxVumtvw== X-Gm-Gg: ASbGncuEqrsH5lm2MZlN57D2nTKhrkdXySbhVDjt2kQ/5sKaSdklerzyoMGVpZZ17Nz fmpwMxC3Lr3OMEd6FTDTwBE/T7nDlIO75gSAt+y7Zvrg1YhR2/+gbVpmruO2yuL1brKGQ2xHhU3 o= X-Received: by 2002:a05:600c:a087:b0:43c:fe5e:f040 with SMTP id 5b1f17b1804b1-43ea7cc3841mr18843305e9.23.1743496782611; Tue, 01 Apr 2025 01:39:42 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE0kwY5dhCkHMW9G5dKBr8YPgzHbkoG1f30MbBmjyMJOAnDXikeQGw9fBRU7sId9Emw+vGv3P5g3wE01mk/R6E= X-Received: by 2002:a05:600c:a087:b0:43c:fe5e:f040 with SMTP id 5b1f17b1804b1-43ea7cc3841mr18843075e9.23.1743496782268; Tue, 01 Apr 2025 01:39:42 -0700 (PDT) MIME-Version: 1.0 References: <20250401002633.738345-1-saman@enumclass.cc> In-Reply-To: From: Paolo Bonzini Date: Tue, 1 Apr 2025 10:39:31 +0200 X-Gm-Features: AQ5f1JqsI5Wk-7grYWKZhpRc4wqm-WONUiUiQku6LhaeV6zNKQqFIfJkzJBTEdU Message-ID: Subject: Re: [PATCH] Rust: Add tracing and logging support for Rust code To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= Cc: saman , qemu-devel , Stefan Hajnoczi , qemu-rust@nongnu.org, Mads Ynddal , Manos Pitsidianakis X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: VltOiLZt5wHT9hk6Edvwx8pvwFi2Ew9okU8jmstEFrQ_1743496783 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000005ff02e0631b37aa3" Received-SPF: pass client-ip=170.10.133.124; envelope-from=pbonzini@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -32 X-Spam_score: -3.3 X-Spam_bar: --- X-Spam_report: (-3.3 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-rust@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: QEMU Rust-related patches and discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2025 08:39:49 -0000 --0000000000005ff02e0631b37aa3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Il mar 1 apr 2025, 10:27 Daniel P. Berrang=C3=A9 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 :| > > > --0000000000005ff02e0631b37aa3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Il mar 1 apr 2025, 10:27 Daniel = P. Berrang=C3=A9 <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.=C2=A0 With this cha= nge
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=C2=A0 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 c= onverting printf strings to Rust format strings and possibly *more* efficie= nt. 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. Introd= ucing 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.

Pa= olo

With regards,
Daniel
--
|: https://berrange.com=C2=A0 =C2=A0 =C2=A0 -o-=C2=A0 =C2=A0 https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-o-=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://fstop138.berrange= .com :|
|: https://entangle-photo.org=C2=A0 =C2=A0 -o-=C2=A0 =C2=A0= https://www.instagram.com/dberrange :|


--0000000000005ff02e0631b37aa3--