Alex Bennée <alex.ben...@linaro.org> writes:
[snip]
>
> Another potential area for conversion was the VirtIO device and
> vhost-user code which could expect to re-use a lot of the crates from
> the rust-vmm project. However this did bring up the point of maintainer
> buy in. Stefan brought up the example of the simpletrace rewrite which
> while it may have brought some advantages he felt he was unable to take
> as a maintainer as he was not familiar with Rust at that point.
I'm especially interested in how QEMU can leverage the rust-vmm project,
though to what extent that is beneficial for QEMU is yet to be discussed:
a. An increasing number of virtio device types are being developed in
the vhost-device crate which is expected to be reused by monolithic
VMMs. However, QEMU can already talk to those backends via the
vhost-user protocol. I'm not sure if it is necessary to go one step
further by integrating those backends into the QEMU binary. One benefit
in my mind is to keep VGA compatibility (which virito-gpu via vhost-user
does not provide), but that may not seem to be that significant.
b. Concerning the virtio basic facilities (virtqueues, config space,
etc.) and the vhost-user protocol, QEMU already has an implementation
that has been tested for years. As Daneil has pointed out, replacing
them with rust-vmm components puts risks QEMU's short/mid-term quality.
Comments on this from the community, esp. the maintainers, are extremely
valuable and highly appreciated.
>
> Developer Expertise and Language policies
> -----------------------------------------
>
[snip]
>
> How will this affect QEMU's declared security boundaries? Do we need to
> develop a policy on the use of unsafe{} sections in the code and how we
> interact with the wider C code?
+1 for a policy on unsafe code in Rust because inapproriate use of
unsafe code can put Rust's safety guarantees in vain.
Especially for unsafe functions or traits, their extra safety conditions
shall be stated in the code so that their users are aware of them and
can check if such conditions are met in their context. That also makes
any change to those safety conditions explicit.
>
> One of the promises of Rust is its support for inline unit test
> integration although there was a little confusion about how this works
> in practice. Are separate test binaries created with just the code under
> test or is there a unit testable build of QEMU itself? Does this still
> work with mixed C and Rust code?
My experience with Rust unit testing is that cargo generate a separate
executable that links the crate under test, dependencies of that crate
and a test driver. In that sense, I don't think mixed C/Rust code can be
unit-tested in the current draft of Rust enabling where the C and Rust
code are separately built into libraries and finally linked together.
--
Best Regards
Junjie Mao
