[Rust-VMM] Proposal for contribution and crate approval process

Paolo Bonzini pbonzini at redhat.com
Thu Feb 28 09:42:44 UTC 2019

On 28/02/19 09:51, Christophe de Dinechin wrote:
> I understand your concern, but I also disagree about the “single
> binary” approach. As other have already said, I think the objective
> is to make crates that are reusable in a variety of binaries. That’s
> a good way to identify parts that are reusable, and parts that are
> “details of the implementation”. As a matter of fact, I think it
> would be interesting to start thinking about small binaries that we
> could start working on “right away”, i.e. things that could work
> using only, say, the memory-model crate.

I agree; thinking about "small binaries" and sample users of rust-vmm
crates helps deciding which crates to work on next.  In fact that's also
why it is important to have reference implementations and/or samples at
each step: for use in other reference implementations and/or samples!

For example, a sample vhost-user-blk implementation is probably the
minimal example of what to do with rust-vmm crates.  It would use the
memory-model crate's mmap implementation + the virtqueue abstractions,
so the next obvious steps for rust-vmm are:

1) to port virtqueue code (not necessarily all of virtio) from crosvm
to and firecracker rust-vmm's memory-model crate;

2) to write a vhost-user crate and a sample code for that

Another possibility could be a userspace IP stack (or a binding to
libslirp which we're extracting from QEMU to a standalone library) and a
sample vhost-user-net implementation.  But in any case virtio comes
first, and Jiang is already working on it as far as I understand.

In parallel with this, crosvm and firecracker can and should be ported
to rust-vmm's memory-model (which actually will be renamed to
vm-memory).  In turn, this is not an all-or-nothing thing and it can
start with just renaming the methods to the names used in rust-vmm.

> The whole rust-vmm project also builds on a lot of earlier designs,
> experiments and experience. As a result, core design concepts are
> already “just there” simply by citation. For example, the
> memory-model crate currently being defined began as a simple
> extraction of existing code by Jiang. Paolo then started doing a lot
> of heavy lifting to isolate generic code and concepts. To me,
> discussing design changes based on real code proposals such as this
> is an effective way to move forward.

Again I agree, and the simple extraction of existing code is already a
huge step for those that, like me, have little or no exposure to crosvm
and firecracker.  If you can look at a small amount of battle-tested
code with a fresh mind, the abstractions just come to you naturally.


More information about the Rust-vmm mailing list