From: Zhao Liu <zhao1.liu@intel.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, qemu-rust@nongnu.org
Subject: Re: [PATCH 06/14] rust: qemu-api: add bindings to Error
Date: Tue, 3 Jun 2025 17:29:19 +0800 [thread overview]
Message-ID: <aD7AbxghCc5VYDhu@intel.com> (raw)
In-Reply-To: <877c1uffj3.fsf@pond.sub.org>
> > + /// Equivalent of the C function `error_propagate`. Fill `*errp`
>
> Uh, is it? Let's see...
>
> > + /// with the information container in `self` if `errp` is not NULL;
> > + /// then consume it.
> > + ///
> > + /// # Safety
> > + ///
> > + /// `errp` must be a valid argument to `error_propagate`;
>
> Reminder for later: the valid @errp arguments for C error_propagate()
> are
>
> * NULL
>
> * &error_abort
>
> * &error_fatal
>
> * Address of some Error * variable containing NULL
>
> * Address of some Error * variable containing non-NULL
>
> The last one is *not* valid with error_setg().
>
> > + /// typically it is received from C code and need not be
> > + /// checked further at the Rust↔C boundary.
> > + pub unsafe fn propagate(self, errp: *mut *mut bindings::Error) {
>
> Reminder, just to avoid confusion: C error_propagate() has the arguments
> in the opposite order.
>
> > + if errp.is_null() {
> > + return;
> > + }
> > +
> > + let err = self.clone_to_foreign_ptr();
> > +
> > + // SAFETY: caller guarantees errp is valid
> > + unsafe {
> > + errp.write(err);
> > + }
> > + }
>
> In C, we have two subtly different ways to store into some Error **errp
> argument: error_setg() and error_propagate().
>
> Their obvious difference is that error_setg() creates the Error object
> to store, while error_propagate() stores an existing Error object if
> any, else does nothing.
>
> Their unobvious difference is behavior when the destination already
> contains an Error. With error_setg(), this must not happen.
> error_propagate() instead throws away the new error. This permits
> "first one wins" error accumulation. Design mistake if you ask me.
>
> Your Rust propagate() also stores an existing bindings::Error. Note
> that "else does nothing" doesn't apply, because we always have an
> existing error object here, namely @self. In the error_propagate() camp
> so far.
>
> Let's examine the other aspect: how exactly "storing" behaves.
>
> error_setg() according to its contract:
>
> If @errp is NULL, the error is ignored. [...]
>
> If @errp is &error_abort, print a suitable message and abort().
>
> If @errp is &error_fatal, print a suitable message and exit(1).
>
> If @errp is anything else, *@errp must be NULL.
>
> error_propagate() according to its contract:
>
> [...] if @dst_errp is NULL, errors are being ignored. Free the
> error object.
>
> Else, if @dst_errp is &error_abort, print a suitable message and
> abort().
>
> Else, if @dst_errp is &error_fatal, print a suitable message and
> exit(1).
>
> Else, if @dst_errp already contains an error, ignore this one: free
> the error object.
>
> Else, move the error object from @local_err to *@dst_errp.
>
> The second to last clause is where its storing differs from
> error_setg().
>
> What does errp.write(err) do? I *guess* it simply stores @err in @errp.
> Matches neither behavior.
>
> If that's true, then passing &error_abort or &error_fatal to Rust does
> not work, and neither does error accumulation. Not equivalent of C
> error_propagate().
I did some simple tests. yes, &error_abort or &error_fatal doesn't work.
Current @errp of realize() can work because @errp points to @local_err
in device_set_realized().
> Is "propagate" semantics what you want here?
>
> If not, use another name.
I guess here we should call C version's error_propagate() instead of
write():
diff --git a/rust/qemu-api/src/error.rs b/rust/qemu-api/src/error.rs
index a91ce6fefaf4..56622065ad22 100644
--- a/rust/qemu-api/src/error.rs
+++ b/rust/qemu-api/src/error.rs
@@ -205,7 +205,7 @@ pub unsafe fn propagate(self, errp: *mut *mut bindings::Error) {
// SAFETY: caller guarantees errp is valid
unsafe {
- errp.write(err);
+ bindings::error_propagate(errp, err);
}
}
---
Then Rust's propagate has the same behavior as C (Of course, here Rust
is actually using C's error_propagate, so the two are equivalent.)
Regards,
Zhao
next prev parent reply other threads:[~2025-06-03 9:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-30 8:02 [PATCH v2 00/14] rust: bindings for Error Paolo Bonzini
2025-05-30 8:02 ` [PATCH 01/14] subprojects: add the anyhow crate Paolo Bonzini
2025-05-30 8:02 ` [PATCH 02/14] subprojects: add the foreign crate Paolo Bonzini
2025-05-30 8:02 ` [PATCH 03/14] util/error: expose Error definition to Rust code Paolo Bonzini
2025-06-03 3:06 ` Zhao Liu
2025-05-30 8:02 ` [PATCH 04/14] util/error: allow non-NUL-terminated err->src Paolo Bonzini
2025-06-02 10:47 ` Markus Armbruster
2025-05-30 8:02 ` [PATCH 05/14] util/error: make func optional Paolo Bonzini
2025-06-02 10:52 ` Markus Armbruster
2025-05-30 8:02 ` [PATCH 06/14] rust: qemu-api: add bindings to Error Paolo Bonzini
2025-06-02 13:18 ` Markus Armbruster
2025-06-03 9:29 ` Zhao Liu [this message]
2025-06-03 10:32 ` Markus Armbruster
2025-06-03 15:05 ` Paolo Bonzini
2025-06-04 5:01 ` Markus Armbruster
2025-06-04 19:19 ` Paolo Bonzini
2025-06-05 6:14 ` Markus Armbruster
2025-06-03 15:37 ` Paolo Bonzini
2025-05-30 8:02 ` [PATCH 07/14] rust: qemu-api: add tests for Error bindings Paolo Bonzini
2025-05-30 8:03 ` [PATCH 08/14] rust: qdev: support returning errors from realize Paolo Bonzini
2025-05-30 8:03 ` [PATCH 09/14] rust/hpet: change type of num_timers to usize Paolo Bonzini
2025-05-30 8:03 ` [PATCH 10/14] hpet: adjust VMState for consistency with Rust version Paolo Bonzini
2025-06-03 3:11 ` Zhao Liu
2025-05-30 8:03 ` [PATCH 11/14] hpet: return errors from realize if properties are incorrect Paolo Bonzini
2025-05-30 8:03 ` [PATCH 12/14] rust/hpet: " Paolo Bonzini
2025-05-30 8:03 ` [PATCH 13/14] rust/hpet: Drop BqlCell wrapper for num_timers Paolo Bonzini
2025-05-30 8:03 ` [PATCH 14/14] docs: update Rust module status Paolo Bonzini
2025-06-03 3:09 ` Zhao Liu
2025-06-02 7:49 ` [PATCH v2 00/14] rust: bindings for Error Markus Armbruster
2025-06-02 9:45 ` Paolo Bonzini
2025-06-03 9:35 ` Zhao Liu
-- strict thread matches above, loose matches on Subject: below --
2025-06-05 10:15 [PATCH v3 " Paolo Bonzini
2025-06-05 10:15 ` [PATCH 06/14] rust: qemu-api: add bindings to Error Paolo Bonzini
2025-06-05 12:06 ` Markus Armbruster
2025-06-05 13:45 ` Zhao Liu
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=aD7AbxghCc5VYDhu@intel.com \
--to=zhao1.liu@intel.com \
--cc=armbru@redhat.com \
--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).