On 27/11/18 10:33, Jon Olson wrote:
On Tue, Nov 27, 2018, 1:13 AM Paolo Bonzini <email@example.com mailto:firstname.lastname@example.org wrote:
On 27/11/18 06:42, Liguori, Anthony via Kata-hypervisor wrote: > On a personal note, I absolutely love Rust! I think the language was made for this purpose. Yes, it's very interesting. I hope to introduce Rust in QEMU too, and I'd love to discuss with you (also based on your QEMU background) what you think is the best way to hook Rust and C together.
Go the other direction -- use the C as spec, and build up the Rust to meet it.
Don't marry C and Rust unless you have a use case that requires it.
My use case is that, for example, having virtqueue processing in Rust would give me 90% of the benefit of a full rewrite already. It's possibly the only part of QEMU that runs all the time, is exposed to untrusted data and needs to be damn fast.
For the specific case of virtqueues, pushing them out of process by writing a vhost-user server in Rust would make sense too. However, you still would not be able to reduce the attack surface of the control plane.
QEMU being written in C rather than C++ makes it much simpler to use Rust's FFI; the complicated part of C+Rust seems to be mapping lifetimes back to e.g. C reference counts. That probably means one of these:
1) writing something like Rc or Arc, that sends ref and unref operations back to C. In theory the advantage is that you write the least Rust code, in practice your reimplementation would be much less polished than the Rust standard library so I don't think it's a good idea.
2) converting the core data structures to Rust and then writing a C wrapper for them. The disadvantage is that you have to work bottom-up. On the other hand, the core data structures are also where we have the best testcases so it's probably the easiest.
3) for very special cases such as functions that absolutely have to be inlined, writing the same code twice, in both Rust and C. This would be the case for something like RCU's read side.
A while ago I looked at https://github.com/crossbeam-rs/crossbeam-epoch, and it seemed like it could be adapted to become an RCU implementation and/or a wrapper for QEMU's RCU. This would be very important since RCU is used for several central data structures in QEMU (e.g. the memory regions). Paolo _______________________________________________ Kata-hypervisor mailing list Kataemail@example.com <mailto:Katafirstname.lastname@example.org> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-hypervisor