Understood your guys' motivation. Thanks for clarification;) Chao
-----Original Message----- From: Paolo Bonzini [mailto:pbonzini@redhat.com] Sent: Thursday, February 28, 2019 5:43 PM To: Christophe de Dinechin dinechin@redhat.com; Peng, Chao P chao.p.peng@intel.com Cc: Jonathan Bryce jonathan@openstack.org; rust-vmm@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:
to port virtqueue code (not necessarily all of virtio) from crosvm to and firecracker rust-vmm's memory-model crate;
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