Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release v0.6 #148

Merged
merged 2 commits into from
Aug 5, 2021
Merged

Release v0.6 #148

merged 2 commits into from
Aug 5, 2021

Conversation

jiangliu
Copy link
Member

@jiangliu jiangliu commented Jun 6, 2021

Release vm-memory v0.6, with latest dirty track bitmap implementation.

sboeuf
sboeuf previously approved these changes Jun 7, 2021
@andreeaflorescu
Copy link
Member

@jiangliu can we push this a bit until we fix this comment: #125 (comment)

@lauralt wants to submit a PR with it.

@jiangliu
Copy link
Member Author

jiangliu commented Jun 7, 2021

@jiangliu can we push this a bit until we fix this comment: #125 (comment)

@lauralt wants to submit a PR with it.

sure, then I will try to create a patch for #149

@bonzini
Copy link
Member

bonzini commented Jun 8, 2021

I wonder if it's a good idea to break the exported types due to the dirty bitmap implementation. Perhaps export the new version from some sub-package, and leave those exported directly from vm_memory as aliases with () as the bitmap type?

@jiangliu
Copy link
Member Author

I wonder if it's a good idea to break the exported types due to the dirty bitmap implementation. Perhaps export the new version from some sub-package, and leave those exported directly from vm_memory as aliases with () as the bitmap type?

I have give a try, but it always breaks existing users of GuestMemoryRegion. For example, I have tried to rename "GuestMemoryRegion" to "GuestMemoryRegionImpl", and defines

pub trait GuestMemoryRegion: GuestMemoryRegionImpl<B = ()> {}

Then existing users need to "use GuestMemoryRegionImpl" too, which still breaks:(

@jiangliu
Copy link
Member Author

jiangliu commented Jul 1, 2021

I have tried several times to avoid breaking compatibility but failed:(
So should we release v1.0.0 instead of v0.6.0?

@andreeaflorescu
Copy link
Member

We don't really give any guarantees related to the interface until we reach 1.0.0. I think we were also considering some other interface simplifications (#141), and I would be more inclined to first agree on those, implement them, and only then release 1.0.0.

For this one, I would be fine with 0.6.0 even if we break the interface.

@jiangliu jiangliu force-pushed the v0.6 branch 3 times, most recently from 668a947 to 3f961fc Compare August 3, 2021 12:04
There's a race window in observe_mutate() and we have observed it
breaking the coverage test several times. So fix it by using Barrier.

Signed-off-by: Liu Jiang <[email protected]>
@jiangliu jiangliu force-pushed the v0.6 branch 2 times, most recently from a294dc6 to 41f24a1 Compare August 3, 2021 12:09
@@ -1574,6 +1576,7 @@ mod tests {
// somehow and this helps to ensure the sleep actually happens before the store rather then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would update the comments, so they do not mention about sleep anymore.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

Release vm-memory v0.6, with latest dirty track bitmap implementation.

Signed-off-by: Liu Jiang <[email protected]>
@jiangliu jiangliu merged commit acd281e into rust-vmm:master Aug 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants