bug#36117: [PATCH 4/4] services/qemu-binfmt: Use the F flag and the static output of QEMU.

["Ludovic Courtès" <ludo@gnu.org>]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Fixes <https://issues.guix.gnu.org/36117>.
>
> Before this change, the 'binfmt_misc' entries registered for QEMU would not be
> usable in container contexts outside of guix-daemon (without manually bind
> mounting file names).
>
> For example:
>
> $ docker run --rm arm32v7/debian true
> standard_init_linux.go:207: exec user process caused "no such file or directory"
>
> After this change, any container can make use of the QEMU binfmt_misc
> registrations, as their corresponding QEMU static binaries are fully
> pre-loaded by the kernel.

[...]

> +++ b/gnu/services/virtualization.scm
> @@ -554,13 +554,14 @@ potential infinite waits blocking libvirt."))
>  ;;;
>  
>  ;; Platforms that QEMU can emulate.
> -(define-record-type <qemu-platform>
> -  (qemu-platform name family magic mask)
> +(define-record-type* <qemu-platform>

Since this is for internal consumption, I’m in favor of keeping plain
‘define-record-type’.  Also, I don’t think the “F” flag belongs here,
it’s mostly orthogonal.

>  (define qemu-binfmt-service-type
>    ;; TODO: Make a separate binfmt_misc service out of this?
>    (service-type (name 'qemu-binfmt)
> @@ -800,9 +833,7 @@ given QEMU package."
>                                            (const
>                                             (list %binary-format-file-system)))
>                         (service-extension shepherd-root-service-type
> -                                          qemu-binfmt-shepherd-services)
> -                       (service-extension guix-service-type
> -                                          qemu-binfmt-guix-chroot)))
> +                                          qemu-binfmt-shepherd-services)))

As discussed on IRC, the downside of this approach is increased disk and
memory footprint (those big binaries have to be loaded in memory).

One possibility would be to add an option to choose between this and the
current approach, but maybe it’s not worth the maintenance trouble.

Thoughts?

Thanks for fixing this issue!

Ludo’.