On 18/2/25 16:52, Alex Bennée wrote:
Alex Bennée <alex.ben...@linaro.org> writes:
Hi,
The KVM/QEMU community call is at:
https://meet.jit.si/kvmcallmeeting
@
18/02/2025 14:00 UTC
Paolo is going to give another rust update along with an overview of
how a rust backend goes together.
You can view/download the video from:
https://fileserver.linaro.org/s/zQzSmd92ecaT5dN
My notes and few questions for Paolo:
- w.r.t. endianness API, this form seems more natural to my
C background:
let hval: address_space_memory.load::<LE16>(hwaddr);
- w.r.t. VMState I understand we'll have machines with a mix of C
and Rust device model implementations, so we'll have to stick to
the C migration serialization, and can't take benefit of Rust one.
- Can the Fifo implementation in rust/hw/char/pl011/src/device.rs
be extracted as "qemu/fifo32.h"?
- Can we remove native_endian() from rust/qemu-api/src/memory.rs,
as we are trying to get rid of DEVICE_NATIVE_ENDIAN?
- About { embedded / heap allocated } QOM objects: In C developers
don't want to give away the embedded model, as it offers free
type checks (while heap-alloc must use runtime checks). IIUC with
Rust it is the opposite, you mentioned is simpler to get build time
checks with the heap-alloc version, is that right? (I didn't took
particular notes about it). I'm interested because for declarative
dynamic machines modelling, it is simpler to use the heap to allocate
the objects, and I'd like to promote that more.
- I noticed trace event calls are commented, what is the plan?
Regards,
Phil.
