Crate Addition Request: kvm

[andreeaflorescu]

Crate Name: kvm

Short Description

The kvm repository can be a rust workspace containing kvm-ioctls and kvm-bindings crates.

Why is this crate relevant to the rust-vmm project?

Hosting both crates in the same repository allows us to have a few simplifications. The kvm-bindings cannot really be tested independently and kvm-ioctls are using a fixed version of kvm-bindings. We can still publish them as separate crates on crates.io, but at least the development model should be simplified this way because a change in kvm-bindings can have the corresponding change in kvm-ioctls submitted as part of the same PR.

[rbradford]

👍 I think consolidating is a great idea.

[jiangliu]

Agree, a workspace for both kvm-bindings and kvm-ioctls may help to reduce maintain efforts.

[sboeuf]

Cool 👍

[andreeaflorescu]

I've created a repo here to see how things are going: https://github.com/andreeaflorescu/kvm
I have no idea how I can keep the commit history of the initial repositories :( if anyone can help here, I'd be grateful. Otherwise it will all be wiped (sorry).

There are still a few things to do so and the work is non-negligible (setting up proper CI, documentation, update Cargo.toml of the individual crates to specify the changes of repository). We should figure out if we want to invest the effort here. Depending on the path we go with serialization of bindings, having all the kvm-related functionality in a single repository might ensure smoother sailing for ideas such as a kvm-bindings proxy.

[rbradford]

@andreeaflorescu Look into git filter-branch

[gurjeet]

@andreeaflorescu , FWIW, I'm researching ways to merge the two repos while keeping the history. As of now I have investigated and ruled out the option of Subtree Merging as described here.

AIUI, you want kvm-bindings repo to be a subdirectory of kvm-ioctls repo. Correct? I am not sure of its implications on being able to serve both as Crates, but that's what I'm trying to do.

[andreeaflorescu]

@andreeaflorescu , FWIW, I'm researching ways to merge the two repos while keeping the history. As of now I have investigated and ruled out the option of Subtree Merging as described here.

AIUI, you want kvm-bindings repo to be a subdirectory of kvm-ioctls repo. Correct? I am not sure of its implications on being able to serve both as Crates, but that's what I'm trying to do.

Not really, I would like kvm to be workspace with two crates: kvm-ioctls and kvm-bindings. I do not want kvm-ioctls containing the bindings (at least not for now). The structure I was looking for is here: https://github.com/andreeaflorescu/kvm

[connorkuehl]

I've created a repo here to see how things are going: https://github.com/andreeaflorescu/kvm
I have no idea how I can keep the commit history of the initial repositories :( if anyone can help here, I'd be grateful. Otherwise it will all be wiped (sorry).

@andreeaflorescu I played around with this, but the caveat for my solution is that the history of one repo gets stacked on top of the history of the other repo.

$ git clone https://github.com/rust-vmm/kvm-ioctls
$ git clone https://github.com/rust-vmm/kvm-bindings
$ cd kvm-ioctls
$ git format-patch --stdout --root --relative > ../kvm-ioctls.patch
$ cd ../kvm-bindings
$ git format-patch --stdout --root --relative > ../kvm-bindings.patch
$ cd ..
$ mkdir kvm
$ cd kvm
$ git init
$ mkdir kvm-ioctls kvm-bindings
$ git am --directory kvm-bindings ../kvm-bindings.patch
$ git am --directory kvm-ioctls ../kvm-ioctls.patch
$ # Add `Cargo.toml` in the workspace root, etc.

[andreeaflorescu]

@connorkuehl thanks for the suggestion! I don't really see a problem with that. I guess what is important is to have a history. If people are going to look at the full history, it will look confusing, but otherwise I think that is a neat solution! I'd say we go with it. @rbradford @jiangliu @sboeuf do you have something else in mind?

[acatangiu]

+1