On Tue, May 06, 2025 at 05:26:12PM +0800, Zhao Liu wrote: > > > "enable Rust" supports v1.77 and "enable all devices written in Rust" > > > supports v1.83, correct? > > > > Both support v1.83 only. However, if Rust is missing or old, "enable > > all devices written in Rust" will fail compilation (e.g. Kconfig would > > fail for ARM/x86 targets due to unsatisfiable CONFIG_PL011); > > In this case, a brand new Rust device (without a corresponding C > version) would be unable to compile on the above platforms which don't > support v1.83. I'm not sure if this is an acceptable limitation or > policy. (Has there been a similar case in history?) > > > "enable Rust" will simply pick the C version of the PL011 and HPET devices. > > I support this, at least the compatibility with the old QEMU won't be > broken! Then all C devices rewritten in Rust can be covered by this > category.
I don't really like this because it perpetuates a state where we have parallel implementations of devices that have to be kept in sync. If we're re-writing C devices in Rust, we need to be able to promptly drop the C impl once the Rust impl is feature complete. Keeping 2 impls is a general maint burden, as well as an ongoing vmstate compatibility danger if a change in one impl is not matched by an identical change in the other impl. IMHO having Rust declared supported in QEMU should be aligned with being able to drop C impls of any ported devices. 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 :|
