On Fri, Sep 15, 2023 at 07:33:32AM -0400, Stefan Hajnoczi wrote: > The library approach worked well for libblkio but the overhead of > creating a separate shared library and shipping it is significant. > When QEMU is the only user of some code, then it should definitely be > part of QEMU. Also, when QEMU needs early access to code that isn't > widely available yet, then bundling it inside QEMU until packages are > available also seems reasonable to me (I think we already do that for > libvfio-user and maybe other libraries).
Yep, avoiding the public shared library significantly cuts down the maint burden, as you can freely adapt the exposed C FFI API to suit QEMU's needs and not worry about ABI compatibility. > I would prefer it if we minimize Rust wrappers for C APIs and instead > focus on using Rust to build new subsystems. Writing and maintaing two > sets of the same API is expensive and I hope we don't get bogged down > keeping C and Rust APIs in sync. That said, I think there's an > argument for wrapping core QEMU APIs needed for device emulation (e.g. > DeviceState, PCIDevice) because of the security benefits of writing > new device emulation code in Rust. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
