Hi On Tue, Aug 26, 2025 at 6:44 PM Paolo Bonzini <pbonz...@redhat.com> wrote:
> On 8/26/25 16:04, marcandre.lur...@redhat.com wrote: > > From: Marc-André Lureau <marcandre.lur...@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.
