From: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-rust@nongnu.org
Subject: Re: [PATCH 5/9] rust: use MaybeUninit::zeroed() in const context
Date: Fri, 2 May 2025 16:05:08 +0300 [thread overview]
Message-ID: <CAAjaMXb-28SOS7GyJTV6qRjRVramDHMN7JW-jzB-8Nu97GR4ng@mail.gmail.com> (raw)
In-Reply-To: <efc7ef30-002f-4fe7-84dd-1daeedbafaa5@redhat.com>
On Fri, May 2, 2025 at 3:23 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 5/2/25 13:01, Manos Pitsidianakis wrote:
> > On Fri, 02 May 2025 13:23, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> >> ---
> >> docs/devel/rust.rst | 4 --
> >> rust/hw/timer/hpet/src/fw_cfg.rs | 6 +-
> >> rust/qemu-api/src/zeroable.rs | 104 +++++--------------------------
> >> 3 files changed, 18 insertions(+), 96 deletions(-)
> >
> > Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
> >
> > BTW There's this TODO in qom.rs, ObjectImpl trait
> >
> >> /// `&mut T`. TODO: add a bound of
> >> //[`Zeroable`](crate::zeroable::Zeroable)
> >> /// to T; this is more easily done once Zeroable does not require a manual
> >> /// implementation (Rust 1.75.0).
> >> const CLASS_INIT: fn(&mut Self::Class);
>
> Yes, good point. When I wrote the TODO, my idea here was to have some
> kind of
>
> #[derive(Zeroable)]
>
> macro so that the compiler can "confirm" the safety of implementing
> Zeroable by hand.
>
> However, most of the time the class will be just a C-defined class
> (DeviceClass or SysBusDeviceClass), and then it's not even possible to
> add the derive attribute to the declaration.
Yes this makes sense. A benefit of having `#[derive(Zeroable)]` is
avoiding blanket unsafe impls of the trait, since the derive macro
would work only if all fields implement Zeroable (so in a sense, it's
safe as long as the individual field type impls are safe,
transitively). And we can still do manual unsafe impls for everything
from the FFI boundary.
> So adding the bound to
> ObjectType::Class is feasible now that one can just add
>
> unsafe impl Zeroable for bindings::ObjectClass {}
> unsafe impl Zeroable for bindings::DeviceClass {}
> unsafe impl Zeroable for bindings::SysBusDeviceClass {}
> unsafe impl Zeroable for bindings::ResettableClass {}
>
> etc.; in fact it was already possible when Zhao added the impl_zeroed!
> macro in commit aaf3778baaa ("rust/zeroable: Implement Zeroable with
> const_zero macro", 2025-01-28).
>
> Paolo
>
next prev parent reply other threads:[~2025-05-02 13:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-02 10:23 [PATCH 0/9] rust: allow minimum version of 1.77 Paolo Bonzini
2025-05-02 10:23 ` [PATCH 1/9] lcitool: use Rust 1.78 for Debian bookworm Paolo Bonzini
2025-05-02 10:23 ` [PATCH 2/9] rust: use std::ffi instead of std::os::raw Paolo Bonzini
2025-05-02 10:57 ` Manos Pitsidianakis
2025-05-02 10:23 ` [PATCH 3/9] rust: let bilge use "let ... else" Paolo Bonzini
2025-05-02 12:44 ` Manos Pitsidianakis
2025-05-02 10:23 ` [PATCH 4/9] rust: qemu_api_macros: " Paolo Bonzini
2025-05-02 12:45 ` Manos Pitsidianakis
2025-05-02 10:23 ` [PATCH 5/9] rust: use MaybeUninit::zeroed() in const context Paolo Bonzini
2025-05-02 11:01 ` Manos Pitsidianakis
2025-05-02 12:22 ` Paolo Bonzini
2025-05-02 13:05 ` Manos Pitsidianakis [this message]
2025-05-02 10:23 ` [PATCH 6/9] rust: remove offset_of replacement Paolo Bonzini
2025-05-02 10:23 ` [PATCH 7/9] rust: replace c_str! with c"" literals Paolo Bonzini
2025-05-02 10:47 ` Manos Pitsidianakis
2025-05-02 10:53 ` Paolo Bonzini
2025-05-02 10:23 ` [PATCH 8/9] rust: enable clippy::ptr_cast_constness Paolo Bonzini
2025-05-02 11:09 ` Manos Pitsidianakis
2025-05-02 12:28 ` Paolo Bonzini
2025-05-02 18:57 ` Stefan Zabka
2025-05-02 19:32 ` Paolo Bonzini
2025-05-02 10:23 ` [PATCH 9/9] docs: rust: update for newer minimum supported version Paolo Bonzini
2025-05-02 10:54 ` [PATCH 0/9] rust: allow minimum version of 1.77 Manos Pitsidianakis
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=CAAjaMXb-28SOS7GyJTV6qRjRVramDHMN7JW-jzB-8Nu97GR4ng@mail.gmail.com \
--to=manos.pitsidianakis@linaro.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-rust@nongnu.org \
/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).