Skip to content
This repository has been archived by the owner on May 11, 2020. It is now read-only.

Bump to QEMU 4.2.0 #24

Closed
wants to merge 1 commit into from
Closed

Bump to QEMU 4.2.0 #24

wants to merge 1 commit into from

Conversation

dims
Copy link

@dims dims commented May 1, 2020

Fixes #23

Signed-off-by: Davanum Srinivas [email protected]

@dims
Copy link
Author

dims commented May 1, 2020

cc @StefanScherer @justincormack

@dims
Copy link
Author

dims commented May 1, 2020

Never mind looks like this is a big deal and not a one liner !
https://ci-next.docker.com/public/blue/organizations/jenkins/binfmt/detail/PR-24/1/pipeline

Looks like the qemu fork needs to be updated
https://github.com/moby/qemu

@dims
Copy link
Author

dims commented May 2, 2020

Looking at the differences between the forked and upstream qemu for say 4.0.0, 4.1.0:

Looks like the only difference is:
qemu/qemu@7fde162

@dims
Copy link
Author

dims commented May 3, 2020

Funny, looks like golang already tolerates 33 and 64. So we don't really need the fork

64 was added first in golang/go@2aef675
and then 33/32 were as well golang/go@c0e5485

@dims
Copy link
Author

dims commented May 3, 2020

We don't really need to use the fork as the changes are already in
golang to ignore signals 33 and 64 since golang 1.11:

- golang/go@2aef675
- golang/go@c0e5485

Let's just start using qemu/qemu repository directly.

Signed-off-by: Davanum Srinivas <[email protected]>
@thaJeztah
Copy link
Member

Nice find! Looks like we should be able to archive https://github.com/moby/qemu then?

@tuonga
Copy link

tuonga commented May 3, 2020 via email

@dims
Copy link
Author

dims commented May 3, 2020

Bonus : since those 2 golang patches are in golang 1.11 already and currently even 1.11 is gone out of support, we should totally moth ball the moby/qemu repo.

Copy link
Member

@StefanScherer StefanScherer left a comment

Choose a reason for hiding this comment

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

Thanks for finding and linking the fixes in golang. This looks reasonable to me.

LGTM

@thaJeztah
Copy link
Member

Oh; I see there's one open PR against the fork; moby/qemu#7 - @tuonga do you know if that's still needed, and if so, should that be upstreamed directly?

@tuonga
Copy link

tuonga commented May 4, 2020 via email

justincormack added a commit to justincormack/linuxkit that referenced this pull request May 4, 2020
This has fixed a lot of outstanding emulation issues, see comments
in docker/binfmt#24

Signed-off-by: Justin Cormack <[email protected]>
@thaJeztah
Copy link
Member

Also had a chat with @justincormack about archiving the moby/qemu repo; he mentioned it would probably be ok for this repository to use the upstream, but that the moby/qemu repo would still be useful as a place to work on patches (to be upstreamed later)

@dims
Copy link
Author

dims commented May 4, 2020

@justincormack @thaJeztah Done! i've updated this PR to point to qemu/qemu and 4.2.0. Let's ship it! :)

@justincormack
Copy link
Member

I don't think there is any point using this repo at all if it doesn't carry patches, I opened linuxkit/linuxkit#3515 to just update LinuxKit to use 4.2.0, this was the original source of the binfmt package.

@dims
Copy link
Author

dims commented May 4, 2020

@justincormack so we can close out this repo as well? Nice!

@justincormack
Copy link
Member

Closing in favour of upstream LinuxKit

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"bad record MAC" for linux/s390x
5 participants