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. > To compile and run QEMU with a rust component, sure, you'd use meson. 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 :|
