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

Peng, Chao P chao.p.peng at intel.com
Thu Feb 28 11:21:58 UTC 2019


Understood your guys' motivation. Thanks for clarification;)
Chao
> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini at redhat.com]
> Sent: Thursday, February 28, 2019 5:43 PM
> To: Christophe de Dinechin <dinechin at redhat.com>; Peng, Chao P <chao.p.peng at intel.com>
> Cc: Jonathan Bryce <jonathan at openstack.org>; rust-vmm at lists.opendev.org
> Subject: Re: [Rust-VMM] Proposal for contribution and crate approval process
> 
> 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