Request for answers/documentation

[umarcor]

In the latest docker-for-win update, I saw that this project is mentioned in the changelog. It is also mentioned in the changelog of docker-for-mac:

Docker Desktop Community 2.1.0.1

• Qemu 4.0.0 for cross compiling for ARM

QEMU was mentioned more than two years ago too:

Docker for Windows 1.13.0, 2017-01-19

• Support for arm, aarch64, ppc64le architectures using qemu

Docker for Mac 1.13.0, 2017-01-19

• Support for arm, aarch64, ppc64le architectures using qemu

Furthermore, there is an article about it in docs.docker.com/docker-for-mac/multi-arch, where it is said that up to four target architectures are supported: arm, mips, ppc64le, and even s390x. According to docker/docs#8211, it applies to docker-for-win too.

I also found that either this project is based on linuxkit/binfmt or the other way round. According to linuxkit/linuxkit#3342, pushing some change from here was/is expected (I couldn't find the PR that @StefanScherer mentioned, tho).

---

I am the maintainer of dbhi/qus, which comprises a set of scripts and docker images to run any of the following combinations:

• Host: amd64, i386, arm64v8, arm32v7, arm32v6, s390x and ppc64le.
• Target: amd64, i386, arm64v8, arm32v7, arm32v6, s390x, ppc64le, mips and mips64el.

The main differences compared to this project are:

• In dbhi/qus:
  • Images for multiple host architectures are provided.
  • Additional target architectures are provided.
  • It is possible to optionally limit/select the list of QEMU binaries to be registered on the host.
  • It is possible to remove/reset all the registered interpreters.
• In docker/binfmt:
  • The logic is embedded in a static binary written in golang.

NOTE: dbhi/qus is based on an enhanced qemu-binfmt-conf.sh and a companion register.sh script. As a result, a shell is required and images are based on busybox instead of scratch.

---

I'd like to understand which is the scope and which are the expected use cases of this project/repo, in order to update https://github.com/dbhi/qus#similar-projects-blog-posts-and-other-references accordingly and hopefully help enhance both projects. @StefanScherer, I'd be so glad if you could answer the following questions:

• Is docker/binfmt automatically executed on both docker-for-win and docker-for-mac? If so, the latest changelog should have included e.g. for cross compiling for ARM, ARM64, s390x and others. instead of for cross compiling for ARM only, isn't it?
• The list of target architectures in this project is aarch64, arm, ppc64le and s390x. However, in docs.docker.com/docker-for-mac/multi-arch, mips is listed instead of aarch64. Do the docs need an update?
• What about a regular GNU/Linux host? AFAIK, the user needs to install/get qemu-user-static binaries and then register a set of target architectures with -p yes. I couldn't find any reference in the docs. I'd be so grateful if you could point me to any article. Alternatively, is any update to the docs planned regarding this image and QEMU support in docker?
• Possible feature requests (just tell whether it is worth creating a separate issue for any of them):
  • Add missing target architectures (arm32v6, mips and mips64el) to this project.
  • Provide images for i386, arm64v8, arm32v7, arm32v6, s390x and ppc64le hosts, and convert docker/binfmt into a multi-arch manifest.
  • Add CLI options to the golang application to:
    • Select/limit the list of target architectures to be registered.
    • Clean a list of registered architectures.

Overall, I'd like to make dbhi/qus converge with docker/binfmt and linuxkit/binfmt.

[justincormack]

1. yes this is shipped and automatically installed on Docker Dekstop for Mac and Windows
2. we do not support mips, probably docs need an update
3. this project is largely for Mac and Windows; generally we expect Linux users to use their distro provided versions or some other means of configuring.
4. there is no point in providing mips or mips64el as there are no Docker base images for those architectures. There might be some reason to provide arm32v6 but there have been no asks for it that I am aware of, all the binaries will generally run on arm32v7
5. Changing the target set is not a request we have had; users can re-register handlers if they know what they are doing.

[umarcor]

@justincormack, thanks a lot!

1. yes this is shipped and automatically installed on Docker Dekstop for Mac and Windows
2. we do not support mips, probably docs need an update

Should I open a PR somewhere else or will you track it on your own?

3. this project is largely for Mac and Windows; generally we expect Linux users to use their distro provided versions or some other means of configuring.

I understand that. However, I think it'd be good to add a reference in the docs. This sentence might be enough, along with some refs such as those listed as 'further info' in https://github.com/dbhi/qus#overview.

4. there is no point in providing mips or mips64el as there are no Docker base images for those architectures. There might be some reason to provide arm32v6 but there have been no asks for it that I am aware of, all the binaries will generally run on arm32v7

The use case is development of apps for devices such as RPi2. Although both arm32v6 and arm32v7 can run on armv7 (or armv8, i.e. aarch32) devices, the opposite will not work. Thus, images for arm32v6 hosts are required in order to build multiarch images that can run on RPi2.

Overall, providing targets such as armv6 or mips is meant for testing cross-compiled binaries (e.g. https://github.com/ASMImproved/qemu-mips-docker). Moreover, supporting armv6 as a host allows to avoid cross-compilation (just as it is now supported for aarch64).

5. Changing the target set is not a request we have had; users can re-register handlers if they know what they are doing.

The point is that I find it great for docker/binfmt to be written in golang, since it allows to distribute it as a static executable. I think that other users/projects could greatly benefit from it. Precisely, I think it might be interesting to enhance it with spf13/cobra and upstream it as an (optional) replacement for qemu-binfmt-conf.sh. wdyt?

[justincormack]

The upstream for the Go binfmt code is https://github.com/linuxkit/linuxkit/tree/master/pkg/binfmt not here.

[justincormack]

This repo is being deprecated in favourof https://github.com/linuxkit/linuxkit/tree/master/pkg/binfmt