search

rust-vmm / vm-virtio

virtio implementation
Apache License 2.0
366 stars 87 forks source link

virtio-queue: build: Relax vm-memory dependency #159

Closed rbradford closed 2 years ago

rbradford commented 2 years ago

This allows the use of newer versions of vm-memory and matches with other crates (e.g. vhost, linux-loader, etc) who also have such a relaxed vm-memory dependency.

Signed-off-by: Rob Bradford robert.bradford@intel.com

rbradford commented 2 years ago

I had to update the PR since there were other uses of vm-memory in this repository. But I think you have a fundamental problem with the virtio-vsock crate as that has a strict dependency on virtio-queue 0.2.0 which will be pulled from crates.io with the fixed vm-memory version.

lauralt commented 2 years ago

I had to update the PR since there were other uses of vm-memory in this repository. But I think you have a fundamental problem with the virtio-vsock crate as that has a strict dependency on virtio-queue 0.2.0 which will be pulled from crates.io with the fixed vm-memory version.

Thanks for the heads up, we will probably have a release of virtio-queue sooner than one for the vsock, and we can update then the virtio-queue dependency with 0.3.0.

rbradford commented 2 years ago

I had to update the PR since there were other uses of vm-memory in this repository. But I think you have a fundamental problem with the virtio-vsock crate as that has a strict dependency on virtio-queue 0.2.0 which will be pulled from crates.io with the fixed vm-memory version.

Thanks for the heads up, we will probably have a release of virtio-queue sooner than one for the vsock, and we can update then the virtio-queue dependency with 0.3.0.

The CI is failing because of this very problem because something is trying to link to two the two versions. I think this probably needs manual intervention of making a new release of the virtio-queue crate with the relaxed dependencies.

rbradford commented 2 years ago

I had to update the PR since there were other uses of vm-memory in this repository. But I think you have a fundamental problem with the virtio-vsock crate as that has a strict dependency on virtio-queue 0.2.0 which will be pulled from crates.io with the fixed vm-memory version.

Thanks for the heads up, we will probably have a release of virtio-queue sooner than one for the vsock, and we can update then the virtio-queue dependency with 0.3.0.

The CI is failing because of this very problem because something is trying to link to two the two versions. I think this probably needs manual intervention of making a new release of the virtio-queue crate with the relaxed dependencies.

One solution would be to make the virtio-vsock crate use the virtio-queue crate in the repo instead. This is how the virtio-blk crate does it.

lauralt commented 2 years ago

I had to update the PR since there were other uses of vm-memory in this repository. But I think you have a fundamental problem with the virtio-vsock crate as that has a strict dependency on virtio-queue 0.2.0 which will be pulled from crates.io with the fixed vm-memory version.

Thanks for the heads up, we will probably have a release of virtio-queue sooner than one for the vsock, and we can update then the virtio-queue dependency with 0.3.0.

The CI is failing because of this very problem because something is trying to link to two the two versions. I think this probably needs manual intervention of making a new release of the virtio-queue crate with the relaxed dependencies.

One solution would be to make the virtio-vsock crate use the virtio-queue crate in the repo instead. This is how the virtio-blk crate does it.

Yes, we can also use path together with version. But it's a bit strange, the crates should be as independent as possible, i.e. virtio-vsock build with virtio-queue 0.2.0, and the others with the current HEAD.

rbradford commented 2 years ago

One solution would be to make the virtio-vsock crate use the virtio-queue crate in the repo instead. This is how the virtio-blk crate does it.

My PR now has a patch that does this. After releasing the virtio-queue crate with the relaxed version you can go back to using crates.io

lauralt commented 2 years ago

One solution would be to make the virtio-vsock crate use the virtio-queue crate in the repo instead. This is how the virtio-blk crate does it.

My PR now has a patch that does this. After releasing the virtio-queue crate with the relaxed version you can go back to using crates.io

In this case, can you also update to >=0.8.0? 0.8.0 is fixing a vm-memory bug that can affect the vsock crate, and it would be better to enforce 0.8.0 here.