[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why QEMU should move from C to Rust (clickbait alert ;))
From: |
Stefan Hajnoczi |
Subject: |
Re: Why QEMU should move from C to Rust (clickbait alert ;)) |
Date: |
Fri, 7 Aug 2020 10:39:07 +0100 |
On Thu, Aug 6, 2020 at 12:51 PM Sergio Lopez <slp@redhat.com> wrote:
> 1. Having a reference implementation for a simple device somewhere
> close or inside the QEMU source tree. I'd say vhost-user-blk is a
> clear candidate, given that a naive implementation for raw files
> without any I/O optimization is quite easy to read and understand.
Yes, it's important to have crates that make it easy to build device backends.
The following common areas come to mind:
1. vhost-user protocol and vring APIs.
2. vhost-user conventions for command-line options.
3. Live migration support.
4. Sandboxing (seccomp, etc).
5. Management interface.
They can all be separate crates and you can choose which ones to use.
Rust-vmm and cloud-hypervisor have already started on some of these.
It would be nice to work together.
Stefan
- Re: Why QEMU should move from C to Rust (clickbait alert ;)), (continued)
- Re: Why QEMU should move from C to Rust (clickbait alert ;)),
Stefan Hajnoczi <=
Re: Why QEMU should move from C to Rust (clickbait alert ;)), Alex Carter, 2020/08/21