On Thu, Oct 3, 2024 at 3:29 PM Manos Pitsidianakis <manos.pitsidiana...@linaro.org> wrote: > > WARNING: This series contains a patch with blob diffs (update of python > wheels) and thus problems may arise with your patch workflow. The > revision is available at > https://gitlab.com/epilys/qemu/-/tree/20240814-rust-pl011-v7-v11 for you > to fetch. HEAD is 6ec1d4fb8db2a1d7ba94c73e65d9770371b7857d > > Hello everyone, > > This series adds: > > - build system support for the Rust compiler > - a small Rust library, qemu-api, which includes bindings to QEMU's C > interface generated with bindgen, and qemu-api-macros, a procedural > macro library. > - a proof of concept ARM PL011 device implementation in Rust, chosen for > its low complexity. The device is used in the arm virt machine if qemu > is compiled with rust enabled (./configure --enable-rust [...])
Thanks, I think this is good for committing. There are certainly a lot of things that are still a bit rough, but they can be handled separately. In particular the priorities for the build system should be: - lowering the minimum supported Rust version - completing support for CI and for clippy - possibly, figuring out the magic that Linux uses to run doctests, and port it to meson (ideally upstream meson would do that and also support "cargo doc", but a QEMU-specific implementation would do) As to PL011State, some mostly independent steps could be: - improve initialization to avoid use of raw pointers. Two different ways could be simply to use MaybeUninit<>, or something more complex like the Linux pinned_init crate - write bindings to the Chardev API (probably requires basic support for QOM methods first, for which https://lore.kernel.org/r/all/20240701145853.1394967-1-pbonz...@redhat.com/ has some mostly-developed ideas) - generalize the extern "C" "thunks" that invoke idiomatic-Rust implementations via a reusable trait, in particular: - figuring out the design for the callback design pattern (see for example https://lpc.events/event/18/contributions/1786/attachments/1431/3226/hrtimer%20Rust%20Abstractions.pdf), i.e. - make functions like pl011_realize or pl011_reset generic, so that other devices can reuse them - expand #[derive(Object)] into a more complete design that allows overriding QOM methods, for example taking care of defining the class_init methods I was also wondering if an useful exercise could be to place a level of maturity for each of the files, for example: A: ready for production use, API supports the full functionality available in C B: ready for production use, API should be safe (when possible) and stable C: proof of concept for safe and/or idiomatic Rust code D: still essentially C code Paolo
