qemu-rust.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-block@nongnu.org, hreitz@redhat.com,
	manos.pitsidianakis@linaro.org, qemu-devel@nongnu.org,
	qemu-rust@nongnu.org
Subject: Re: [PATCH 03/11] rust: Add some block layer bindings
Date: Wed, 12 Feb 2025 16:13:33 +0100	[thread overview]
Message-ID: <Z6y6nUo68dIkryOu@redhat.com> (raw)
In-Reply-To: <CABgObfb-MXHYY4eM5LUbiRdOqWFG_CEcM-Xkv+v_dNWMwThKHA@mail.gmail.com>

Am 12.02.2025 um 14:47 hat Paolo Bonzini geschrieben:
> On Wed, Feb 12, 2025 at 2:13 PM Kevin Wolf <kwolf@redhat.com> wrote:
> > Yes, we definitely need some proper bindings there. I'm already tired of
> > writing things like this:
> >
> >     return -(bindings::EINVAL as std::os::raw::c_int)
> >
> > Or even:
> >
> >     return e
> >         .raw_os_error()
> >         .unwrap_or(-(bindings::EIO as std::os::raw::c_int))
> 
> This by the way seemed incorrect to me as it should be
> 
>      return -(e
>          .raw_os_error()
>          .unwrap_or(bindings::EIO as std::os::raw::c_int))
> 
> (leaving aside that raw_os_error does not work on Windows)... But then
> I noticed that read_raw() also does not negate, which causes the error
> to print incorrectly...

Yes, I actually noticed that after sending the email and fixed it (and
another instances of the same) up locally.

> > Which actually already shows that your errno binding patch does the
> > opposite direction of what I needed in this series.
> 
> ... so my patch already helps a bit: you can still change
> 
>     if ret < 0 {
>          Err(Error::from_raw_os_error(ret))
>     } else {
>          Ok(())
>     }
> 
> to
> 
>    errno::into_io_result(ret)?;
>    Ok(())
> 
> and avoid the positive/negative confusion.

No reason to write essentially if (ret != 0) { ret } else { 0 }. This
one should do:

    errno::into_io_result(ret)

And yes, it's already a good improvement.

> Anyhow, I guess the first one wouldn't be much better:
> 
>    return errno::into_negative_errno(ErrorKind::InvalidInput);
> 
> whereas the second could be
> 
>    return errno::into_negative_errno(e);
> 
> But then the first is already a special case; it only happens where
> your bindings are not trivial thanks to the introduction of the
> Mapping type.

Yes, the second one seems like the more important one because the other
one should only happen in bindings eventually. We could still have
something like an errno!(InvalidInput) to make the code in bindings less
verbose.

Or if you have to define the constants anyway - you currently do this
only for Windows, but for into_negative_errno() you might need it on
Linux, too - and it wouldn't be a problem for the constants to be
signed (that they are unsigned is the main reason why it becomes so ugly
with the bindgen constants), you could just make it -errno::EINVAL
again.

Kevin



  reply	other threads:[~2025-02-12 15:13 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-11 21:43 [PATCH 00/11] rust/block: Add minimal block driver bindings Kevin Wolf
2025-02-11 21:43 ` [PATCH 01/11] rust: Build separate qemu_api_tools and qemu_api_system Kevin Wolf
2025-02-12 10:01   ` Paolo Bonzini
2025-02-12 15:29     ` Kevin Wolf
2025-02-12 16:59       ` Paolo Bonzini
2025-02-11 21:43 ` [PATCH 02/11] meson: Add rust_block_ss and link tools with it Kevin Wolf
2025-02-12  7:38   ` Philippe Mathieu-Daudé
2025-02-11 21:43 ` [PATCH 03/11] rust: Add some block layer bindings Kevin Wolf
2025-02-12  9:29   ` Paolo Bonzini
2025-02-12 13:13     ` Kevin Wolf
2025-02-12 13:47       ` Paolo Bonzini
2025-02-12 15:13         ` Kevin Wolf [this message]
2025-02-12 17:16           ` Paolo Bonzini
2025-02-12 19:52             ` Kevin Wolf
2025-02-13 11:06               ` Paolo Bonzini
2025-02-11 21:43 ` [PATCH 04/11] rust/qemu-api: Add wrappers to run futures in QEMU Kevin Wolf
2025-02-12  9:28   ` Paolo Bonzini
2025-02-12 12:47     ` Kevin Wolf
2025-02-12 13:22       ` Paolo Bonzini
2025-02-18 17:25         ` Kevin Wolf
2025-02-11 21:43 ` [PATCH 05/11] rust/block: Add empty crate Kevin Wolf
2025-02-11 21:43 ` [PATCH 06/11] rust/block: Add I/O buffer traits Kevin Wolf
2025-02-12 16:48   ` Paolo Bonzini
2025-02-12 17:22     ` Kevin Wolf
2025-02-12 17:41       ` Paolo Bonzini
2025-02-11 21:43 ` [PATCH 07/11] block: Add bdrv_open_blockdev_ref_file() Kevin Wolf
2025-02-12  7:43   ` Philippe Mathieu-Daudé
2025-02-11 21:43 ` [PATCH 08/11] rust/block: Add driver module Kevin Wolf
2025-02-12 16:43   ` Paolo Bonzini
2025-02-12 17:32     ` Kevin Wolf
2025-02-12 18:17       ` Paolo Bonzini
2025-02-11 21:43 ` [PATCH 09/11] rust/block: Add read support for block drivers Kevin Wolf
2025-02-12 15:05   ` Paolo Bonzini
2025-02-12 20:52     ` Kevin Wolf
2025-02-11 21:43 ` [PATCH 10/11] bochs-rs: Add bochs block driver reimplementation in Rust Kevin Wolf
2025-02-12  7:45   ` Philippe Mathieu-Daudé
2025-02-12 12:59     ` Kevin Wolf
2025-02-12 13:52       ` Philippe Mathieu-Daudé
2025-02-12  9:14   ` Daniel P. Berrangé
2025-02-12  9:41     ` Daniel P. Berrangé
2025-02-12 12:58       ` Kevin Wolf
2025-02-12 13:07         ` Daniel P. Berrangé
2025-02-11 21:43 ` [PATCH 11/11] rust/block: Add format probing Kevin Wolf

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=Z6y6nUo68dIkryOu@redhat.com \
    --to=kwolf@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=manos.pitsidianakis@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --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).