Daniel P. Berrangé <berra...@redhat.com> writes: > On Tue, Jun 11, 2024 at 01:58:10PM +0300, Manos Pitsidianakis wrote: >> On Tue, 11 Jun 2024 13:57, "Daniel P. Berrangé" <berra...@redhat.com> wrote: >> > On Mon, Jun 10, 2024 at 11:29:36PM +0300, Manos Pitsidianakis wrote: >> > > On Mon, 10 Jun 2024 22:37, Pierrick Bouvier >> > > <pierrick.bouv...@linaro.org> wrote: >> > > > Hello Manos, >> > > > > On 6/10/24 11:22, Manos Pitsidianakis wrote: >> > > > > Hello everyone, >> > > > > > > This is an early draft of my work on implementing a very >> > > simple device, >> > > > > in this case the ARM PL011 (which in C code resides in >> > > > > hw/char/pl011.c >> > > > > and is used in hw/arm/virt.c). >> > > > > > > The device is functional, with copied logic from the C code >> > > but with >> > > > > effort not to make a direct C to Rust translation. In other words, do >> > > > > not write Rust as a C developer would. >> > > > > > > That goal is not complete but a best-effort case. To give a >> > > specific >> > > > > example, register values are typed but interrupt bit flags are not >> > > > > (but >> > > > > could be). I will leave such minutiae for later iterations. >> > >> > snip >> > >> > > > Maybe it could be better if build.rs file was *not* needed for new >> > > > devices/folders, and could be abstracted as a detail of the python >> > > > wrapper script instead of something that should be committed. >> > > >> > > >> > > That'd mean you cannot work on the rust files with a LanguageServer, you >> > > cannot run cargo build or cargo check or cargo clippy, etc. That's why I >> > > left the alternative choice of including a manually generated bindings >> > > file >> > > (generated.rs.inc) >> > >> > I would not expect QEMU developers to be running 'cargo <anything>' >> > directly at all. >> > >> > QEMU's build system is 'meson' + 'ninja' with a 'configure' + 'make' >> > convenience facade. >> > >> > Any use of 'cargo' would be an internal impl detail of meson rules >> > for building rust code, and developers should still exclusively work >> > with 'make' or 'ninja' to run builds & tests. >> >> No, that's not true. If I wrote the pl011 device with this workflow I'd just >> waste time using meson. Part of the development is making sure the library >> type checks, compiles, using cargo to run style formatting, to check for >> lints, perhaps run tests. Doing this only through meson is an unnecessary >> complication. > > I don't see why it should waste time, when we ultimately end up calling > the same underlying tools. We need to have a consistent experiance for > developers working on QEMU, not have to use different tools for different > parts of QEMU depending on whether a piece of code happens to be rust > or C.
For example if I wanted to run rust-based unit tests (which I think potentially offer an easier solution than qtest) I would expect that to be done from the normal make/ninja targets. > >> To compile and run QEMU with a rust component, sure, you'd use meson. > > With regards, > Daniel -- Alex Bennée Virtualisation Tech Lead @ Linaro
