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

Samuel Ortiz samuel.ortiz at intel.com
Wed Feb 27 13:25:33 UTC 2019


Hi Chao,

On Wed, Feb 27, 2019 at 12:49:56PM +0000, Peng, Chao P wrote:
> Sounds like a good process to start with.
> 
> Meanwhile my feeling is that we need a high-level project-wide design first. The reason is that the creates are not really standalone projects. They are closely related and most likely they will form up a single binary from user' point of view. They should be well designed from the high-level at the very beginning.
> 
> To me, we'd better design the project from the user point of view: it's a single project as a whole. The division of the codes into creates is OK, but that's just kind of internal thing for the project.
>
rust-vmm is a single project and we should be consistent in the way we
build and design crates that are part of the project.
But I think we should be careful about making sure those crates can be
used independently, as much as possible. We don't want to produce one
single VMM out of the rust-vmm crates, we want rust-vmm users to be
able to build custom and configurable VMMs out of them.
We may provide a generic VMM as an example on how to use those crates,
but for now I don't see us providing a canonical/reference, production
ready VMM directly from rust-vmm. And even if we do, this should not be
the drive for the crates, but only a good and performant example for the
rust-vmm crates usage.

> Also every designed creates should meet some release criteria otherwise a failure in one creates may result the failure of the whole project.
>
Yes, I think this is what Andreea had in mind when opening issue #14.


> There are several things we can start with:
> - Discuss #14(https://github.com/rust-vmm/community/issues/14) to come up a 'must have list' that will be included in the first release. 
> - Come up a project-wide high-level design. For example:
>         how to divide the creates
>         how to abstract the common code
>         how creates interact each other and come up possible traits definition
>         what interfaces we want to expose to users...
> - Discuss how code/doc/test will be organized
> - Define process/work flow/governance...
> 
> But even before those, we need understand and write down our requirement clearly so everybody involved will be on the same page.
>
There are some common requirements, but there won't be a one size
fits all set of requirements for a single rust-vmm based VMM.

> Just my thoughts. Welcome for further discussion.
Thanks for the input.

Cheers,
Samuel.

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.




More information about the Rust-vmm mailing list