From: "Marc-André Lureau" <marcandre.lureau@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, "Daniel P. Berrangé" <berrange@redhat.com>,
qemu-rust@nongnu.org,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Manos Pitsidianakis" <manos.pitsidianakis@linaro.org>
Subject: Re: [RFC 00/18] rust: split qemu-api
Date: Tue, 26 Aug 2025 19:15:21 +0400 [thread overview]
Message-ID: <CAMxuvazgnPAY76PA75t-rUBDHG5rpTQqa+UepizSAMo_0a5VWA@mail.gmail.com> (raw)
In-Reply-To: <e58ea933-f941-44d8-8477-c8298663cc24@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]
Hi
On Tue, Aug 26, 2025 at 6:44 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 8/26/25 16:04, marcandre.lureau@redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> >
> > Hi,
> >
> > qemu-api is providing bindings for various internal libraries. Instead,
> the
> > bindings requirements should match the various libraries and use the
> minimal set
> > of dependencies.
> >
> > An initial Rust-only "common" crate is introduced, then "util" (for
> libqemuutil,
> > without bql), "migration" (so it doesn't depend on bql), "bql", "qom"
> (arguably,
> > bql shouldn't be required?), and "chardev", "system", "hwcore". Finally
> the
> > qemu-api crates are renamed and repurposed.
> >
> > This involves a lot of code churn, so hopefully it can be reviewed and
> merged
> > early and iterated upon :)
>
> The one comment that I would like to handle before merging, is that I'd
> prefer to keep the preludes and, in fact, even add more exports to them
> since they can now be chosen per-crate. Ideally, many of the crates
> you've crated would be accessed through many "use xyz::prelude::*"
> statements.
>
It's not very useful if you have to include all the preludes though :)
Also, prelude feels a bit too much magic and may pollute namespace. In
general, not so many crates provide them and that's usually a good thing
imho, since you can explicitly import what you need, and LSP and good error
report make that fairly trivial.
So, I am not convinced having each crate its own prelude is a good thing,
but I don't care much. Can easily be added back though.
>
> Also, if I understood correctly the split util/errno.rs can move to
> common/. While it has a dependency on libc, it doesn't need bindgen.
>
>
True, I will move it
> There's a bunch of code duplication for the various bindings.rs and
> build.rs files, which is not ideal but shouldn't grow much more than
> this. I wonder if, later, common code across build.rs could be written
> just once by adding a new crate (e.g. "qemu_meson") to the workspace,
> that can be used as a build-dependency.
>
>
I am not sure, but I can try. Alternatively, we can have a build.rs
symlink, if we can guess the module path.
[-- Attachment #2: Type: text/html, Size: 3645 bytes --]
prev parent reply other threads:[~2025-08-26 15:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 14:04 [RFC 00/18] rust: split qemu-api marcandre.lureau
2025-08-26 14:04 ` [RFC 01/18] rust: remove unused global qemu "allocator" marcandre.lureau
2025-08-26 14:04 ` [RFC 02/18] rust: add workspace authors marcandre.lureau
2025-08-26 14:04 ` [RFC 03/18] rust: split Rust-only "common" crate marcandre.lureau
2025-08-26 14:04 ` [RFC 04/18] rust: split "util" crate marcandre.lureau
2025-08-26 14:04 ` [RFC 05/18] rust: move vmstate_clock!() to qdev module marcandre.lureau
2025-08-26 14:04 ` [RFC 06/18] rust: move VMState handling to QOM module marcandre.lureau
2025-08-26 14:04 ` [RFC 07/18] rust: move Cell vmstate impl marcandre.lureau
2025-08-26 18:28 ` Paolo Bonzini
2025-08-26 19:06 ` Marc-André Lureau
2025-08-27 7:35 ` Paolo Bonzini
2025-08-26 14:04 ` [RFC 08/18] rust: split "migration" crate marcandre.lureau
2025-08-26 14:04 ` [RFC 09/18] rust: split "bql" crate marcandre.lureau
2025-08-26 14:04 ` [RFC 10/18] rust: split "qom" crate marcandre.lureau
2025-08-27 6:55 ` Zhao Liu
2025-08-27 8:57 ` Marc-André Lureau
2025-08-27 9:49 ` Paolo Bonzini
2025-08-26 14:04 ` [RFC 11/18] rust: split "chardev" crate marcandre.lureau
2025-08-26 14:04 ` [RFC 12/18] rust: split "system" crate marcandre.lureau
2025-08-26 14:04 ` [RFC 13/18] rust: split "hwcore" crate marcandre.lureau
2025-08-26 14:04 ` [RFC 14/18] rust: rename qemu_api_macros -> qemu_macros marcandre.lureau
2025-08-26 14:53 ` Paolo Bonzini
2025-08-26 20:30 ` Marc-André Lureau
2025-08-26 14:04 ` [RFC 15/18] rust/hpet: drop now unneeded qemu_api dep marcandre.lureau
2025-08-26 14:04 ` [RFC 16/18] rust/pl011: drop dependency on qemu_api marcandre.lureau
2025-08-26 14:04 ` [RFC 17/18] rust: repurpose qemu_api -> tests marcandre.lureau
2025-08-26 14:04 ` [RFC 18/18] docs: update rust.rst marcandre.lureau
2025-08-26 14:44 ` [RFC 00/18] rust: split qemu-api Paolo Bonzini
2025-08-26 14:55 ` Manos Pitsidianakis
2025-08-26 15:22 ` Marc-André Lureau
2025-08-26 15:33 ` Paolo Bonzini
2025-08-26 15:15 ` Marc-André Lureau [this message]
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=CAMxuvazgnPAY76PA75t-rUBDHG5rpTQqa+UepizSAMo_0a5VWA@mail.gmail.com \
--to=marcandre.lureau@redhat.com \
--cc=berrange@redhat.com \
--cc=manos.pitsidianakis@linaro.org \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.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).