Daniel P. Berrangé <berra...@redhat.com> writes: > On Mon, May 27, 2024 at 04:14:15PM +0800, Zhao Liu wrote: >> Hi maintainers and list, >> >> This RFC series attempts to re-implement simpletrace.py with Rust, which >> is the 1st task of Paolo's GSoC 2024 proposal. >> >> There are two motivations for this work: >> 1. This is an open chance to discuss how to integrate Rust into QEMU. > > I don't think this proposal really triggers that discussion to any > great extent, because 'simpletrace.py' is not a part of the QEMU > codebase in any meaningul way. It is a standalone python script > that just happens to live in the qemu.git repository. > > The difficult questions around Rust integration will arise when we > want to have Rust used to /replace/ some existing non-optional > functionality. IOW, if Rust were to become a mandatory dep of QEMU > that could not be avoided.
We hope to post some PoC device models in Rust soon with exactly that debate in mind. > In fact I kinda wonder whether this Rust simpletrace code could > simply be its own git repo under gitlab.com/qemu-project/...., > rather than put into the monolithic QEMU repo ? That just makes > it a "normal" Rust project and no questions around integration > with QEMU's traditional build system would arise. Do we export the necessary bits for external projects to use? I don't think we've had the equivalent of a qemu-devel package yet and doing so start implying externally visible versioning and deprecation policies for QEMU APIs and data formats. TCG plugins have a header based API but currently everyone builds against their local checkout and we are fairly liberal about bumping the API versions. > > > With regards, > Daniel -- Alex Bennée Virtualisation Tech Lead @ Linaro
