Re: Rust in QEMU roadmap

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Nov 26, 2024 at 06:46:45PM +0100, Paolo Bonzini wrote:
> Feature parity for pl011 device
> '''''''''''''''''''''''''''''''
> 
> Some recent pl011 commits are missing in the Rust version.  Philippe
> volunteered to port them to teach himself Rust.
> 
> Philippe also has a series to implement flow control and better use
> of the PL011 FIFO (IIUC).  Porting this to Rust would be hard right
> now, so its Rust implementation blocked on having chardev bindings.
> 
> Also missing is logging and tracing, but this part should not be a
> blocker for defaulting to --enable-rust.

I think it is OK to miss tracing as an exceptional one-off.

It is highly undesirable though for us to convert more than a
couple of devices (which currently use tracing) without having
tracing working. I consider tracing a critical feature for
supportability of QEMU.

IOW, I'm OK with lack of tracing not being a block for defaulting
to --enable-rust, provided it is accepted as being a high priority
item. Possibly call it a blocker for accepting conversions of
anything beyond pl011 & hpet, that currently has trace points.


> Tracing/logging
> '''''''''''''''
> 
> Tracepoints and logging are not supported yet, and no one has started working
> on it.
> 
> For tracing, it's not clear to me how much C code can be reused and how
> much Rust code can be automatically generated.  This would be a valid
> Outreachy or Summer of Code project, as it has a limited need for unsafe
> code and a well-defined scope.

As mentioned above, IMHO this needs to be treated as a high priority
item. While it would make a good Outreachy/GSoC project, I don't think
we should take that path, as it comes with no guarantee of a successful
timely delivery.

> A pure-Rust implementation would be interesting, but note that the usage
> of printf-style %-based field formatting is pervasive in the tracing
> subsystem.

Note that it is not unbounded printf style formatting. We are actually
pretty restricted in what we can use because our format strings are
required to be compatible with systemtap's formatter which is very
limited compared to C printf().

We've currently got an adhoc check to block use of '%m', but we could
easily make this a much stricter check on '%' and thus make it practical
to auto-convert our printf() style format strings to a format that rust
can use natively.

> Summary:
> 
> * Simple, low priority.

IMHO high priority. I don't want to enable Rust in Fedora/RHEL if
it going to degrade our ability to use tracing to debug production
deployments

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 :|