[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.
Paolo
More information about the Rust-vmm
mailing list