| Message ID | Y5zB+5t5K0AEj6Rn@p100 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | meson: Clean up some dependencies regarding qemu-system | expand |
On 12/16/22 20:07, Helge Deller wrote: > @@ -3581,7 +3581,7 @@ subdir('qga') > > # Don't build qemu-keymap if xkbcommon is not explicitly enabled > # when we don't build tools or system > -if xkbcommon.found() > +if xkbcommon.found() and have_system > # used for the update-keymaps target, so include rules even if !have_tools > qemu_keymap = executable('qemu-keymap', files('qemu-keymap.c', 'ui/input-keymap.c') + genh, > dependencies: [qemuutil, xkbcommon], install: have_tools) > @@ -3596,7 +3596,9 @@ if have_tools > dependencies: [blockdev, qemuutil, gnutls, selinux], > install: true) > > - subdir('storage-daemon') > + if have_system > + subdir('storage-daemon') > + endif > subdir('contrib/rdmacm-mux') > subdir('contrib/elf2dmp') > > @@ -3611,7 +3613,7 @@ if have_tools > subdir('contrib/vhost-user-scsi') > endif > > - if targetos == 'linux' > + if targetos == 'linux' and have_system > executable('qemu-bridge-helper', files('qemu-bridge-helper.c'), > dependencies: [qemuutil, libcap_ng], > install: true, > diff --git a/tools/meson.build b/tools/meson.build > index 10eb3a043f..740d572a94 100644 > --- a/tools/meson.build > +++ b/tools/meson.build > @@ -5,7 +5,7 @@ have_virtiofsd = get_option('virtiofsd') \ > error_message: 'virtiofsd requires libcap-ng-devel and seccomp-devel') \ > .require(have_vhost_user, > error_message: 'virtiofsd needs vhost-user-support') \ > - .disable_auto_if(not have_tools and not have_system) \ > + .disable_auto_if(not have_system) \ > .allowed() > > if have_virtiofsd > These are wrong. qemu-bridge-helper, virtiofsd, qemu-storage-daemon and qemu-keymap *are* tools; if they fail to build due to any dependencies, or due to other compilation issues, you need to add tests to meson.build and check for the cause of the issues. The rest is okay. Paolo
Hi Paolo, On 12/17/22 14:28, Paolo Bonzini wrote: > On 12/16/22 20:07, Helge Deller wrote: >> @@ -3581,7 +3581,7 @@ subdir('qga') >> >> # Don't build qemu-keymap if xkbcommon is not explicitly enabled >> # when we don't build tools or system >> -if xkbcommon.found() >> +if xkbcommon.found() and have_system >> # used for the update-keymaps target, so include rules even if !have_tools >> qemu_keymap = executable('qemu-keymap', files('qemu-keymap.c', 'ui/input-keymap.c') + genh, >> dependencies: [qemuutil, xkbcommon], install: have_tools) >> @@ -3596,7 +3596,9 @@ if have_tools >> dependencies: [blockdev, qemuutil, gnutls, selinux], >> install: true) >> >> - subdir('storage-daemon') >> + if have_system >> + subdir('storage-daemon') >> + endif >> subdir('contrib/rdmacm-mux') >> subdir('contrib/elf2dmp') >> >> @@ -3611,7 +3613,7 @@ if have_tools >> subdir('contrib/vhost-user-scsi') >> endif >> >> - if targetos == 'linux' >> + if targetos == 'linux' and have_system >> executable('qemu-bridge-helper', files('qemu-bridge-helper.c'), >> dependencies: [qemuutil, libcap_ng], >> install: true, >> diff --git a/tools/meson.build b/tools/meson.build >> index 10eb3a043f..740d572a94 100644 >> --- a/tools/meson.build >> +++ b/tools/meson.build >> @@ -5,7 +5,7 @@ have_virtiofsd = get_option('virtiofsd') \ >> error_message: 'virtiofsd requires libcap-ng-devel and seccomp-devel') \ >> .require(have_vhost_user, >> error_message: 'virtiofsd needs vhost-user-support') \ >> - .disable_auto_if(not have_tools and not have_system) \ >> + .disable_auto_if(not have_system) \ >> .allowed() >> >> if have_virtiofsd >> > > These are wrong. qemu-bridge-helper, virtiofsd, qemu-storage-daemon > and qemu-keymap *are* tools; if they fail to build due to any > dependencies, or due to other compilation issues, you need to add > tests to meson.build and check for the cause of the issues. No doubt, those are *tools*. But aren't those only required when you run system- and/or user-emulation? Looking at the packaging of qemu in debian: qemu-system-common debian package consists of thse *tools*: qemu-bridge-helper, vhost-user-gpu, virtfs-proxy-helper, virtiofsd qemu-utils debian package consists of the *utilities*: qemu-img, qemu-io, qemu-nbd IMHO this categorization makes sense. My patch was targetting at making "qemu-utils" possible to build and that's why I think the tools you mention should depend on "have_system". > The rest is okay. Ok, thanks! Helge
On Mon, 19 Dec 2022 at 11:22, Helge Deller <deller@gmx.de> wrote: > > Hi Paolo, > > On 12/17/22 14:28, Paolo Bonzini wrote: > > These are wrong. qemu-bridge-helper, virtiofsd, qemu-storage-daemon > > and qemu-keymap *are* tools; if they fail to build due to any > > dependencies, or due to other compilation issues, you need to add > > tests to meson.build and check for the cause of the issues. > > No doubt, those are *tools*. > But aren't those only required when you run system- and/or user-emulation? > > Looking at the packaging of qemu in debian: > > qemu-system-common debian package consists of thse *tools*: > qemu-bridge-helper, vhost-user-gpu, virtfs-proxy-helper, virtiofsd > > qemu-utils debian package consists of the *utilities*: > qemu-img, qemu-io, qemu-nbd > > IMHO this categorization makes sense. Possibly, but it's not the categorization we use upstream, which splits our binaries into three groups: * system-emulation binaries (qemu-system-arm, etc) * usermode-emulation binaries (qemu-arm, etc) * tools (everything else) (I think the guest-agent may be a fourth group.) thanks -- PMM
On 16/12/22 20:07, Helge Deller wrote: > Reduce amount of compiled code and installed binaries if just the qemu > utilities such as qemu-img, qemu-io and qemu-nbd have to be built. This > helps to make those tools easier available on hosts where qemu-system or > qemu-user isn't supported. > > Reason for this patch is that qemu fail to build on debian for some > seconday non-release architectures (e.g. hppa, sh4, ia64), as can be > seen here: > https://buildd.debian.org/status/package.php?p=qemu&suite=sid > This patch helps to clean up the build so that these tools > can be provided on those platforms in future. > > Signed-off-by: Helge Deller <deller@gmx.de> > index fbdb442fdf..4a499db441 100644 > --- a/qapi/meson.build > +++ b/qapi/meson.build > @@ -51,12 +51,12 @@ qapi_all_modules = [ > 'transaction', > 'virtio', > 'yank', > + 'qdev', > ] > if have_system > qapi_all_modules += [ > 'acpi', > 'audio', > - 'qdev', > 'pci', > 'rdma', > 'rocker', Why do you want qdev out of sysemu?
On 19/12/22 12:31, Peter Maydell wrote: > On Mon, 19 Dec 2022 at 11:22, Helge Deller <deller@gmx.de> wrote: >> >> Hi Paolo, >> >> On 12/17/22 14:28, Paolo Bonzini wrote: >>> These are wrong. qemu-bridge-helper, virtiofsd, qemu-storage-daemon >>> and qemu-keymap *are* tools; if they fail to build due to any >>> dependencies, or due to other compilation issues, you need to add >>> tests to meson.build and check for the cause of the issues. >> >> No doubt, those are *tools*. >> But aren't those only required when you run system- and/or user-emulation? >> >> Looking at the packaging of qemu in debian: >> >> qemu-system-common debian package consists of thse *tools*: >> qemu-bridge-helper, vhost-user-gpu, virtfs-proxy-helper, virtiofsd >> >> qemu-utils debian package consists of the *utilities*: >> qemu-img, qemu-io, qemu-nbd >> >> IMHO this categorization makes sense. > > Possibly, but it's not the categorization we use upstream, > which splits our binaries into three groups: > * system-emulation binaries (qemu-system-arm, etc) Subcategory: * helpers (required to use system-emulation binaries), apparently provided by 'qemu-system-common' on Debian -- except virtiofsd which is not a helper -- > * usermode-emulation binaries (qemu-arm, etc) > * tools (everything else) apparently provided by 'qemu-utils' on Debian (without virtiofsd). @Debian: Maybe virtiofsd deserves its own qemu-virtiofsd package? > > (I think the guest-agent may be a fourth group.) (or part of tools?)
On Mon, 19 Dec 2022 at 11:40, Philippe Mathieu-Daudé <philmd@linaro.org> wrote: > > On 19/12/22 12:31, Peter Maydell wrote: > > On Mon, 19 Dec 2022 at 11:22, Helge Deller <deller@gmx.de> wrote: > >> > >> Hi Paolo, > >> > >> On 12/17/22 14:28, Paolo Bonzini wrote: > >>> These are wrong. qemu-bridge-helper, virtiofsd, qemu-storage-daemon > >>> and qemu-keymap *are* tools; if they fail to build due to any > >>> dependencies, or due to other compilation issues, you need to add > >>> tests to meson.build and check for the cause of the issues. > >> > >> No doubt, those are *tools*. > >> But aren't those only required when you run system- and/or user-emulation? > >> > >> Looking at the packaging of qemu in debian: > >> > >> qemu-system-common debian package consists of thse *tools*: > >> qemu-bridge-helper, vhost-user-gpu, virtfs-proxy-helper, virtiofsd > >> > >> qemu-utils debian package consists of the *utilities*: > >> qemu-img, qemu-io, qemu-nbd > >> > >> IMHO this categorization makes sense. > > > > Possibly, but it's not the categorization we use upstream, > > which splits our binaries into three groups: > > * system-emulation binaries (qemu-system-arm, etc) > > Subcategory: > > * helpers (required to use system-emulation binaries), > apparently provided by 'qemu-system-common' on Debian > -- except virtiofsd which is not a helper -- No, I don't think this is a subcategory. We provide --enable-system --enable-user --enable-tools but there is no --enable-helper and qemu-bridge-helper, etc are built via --enable-tools. > > * usermode-emulation binaries (qemu-arm, etc) > > * tools (everything else) > > apparently provided by 'qemu-utils' on Debian (without > virtiofsd). > > @Debian: Maybe virtiofsd deserves its own qemu-virtiofsd package? > > > > > (I think the guest-agent may be a fourth group.) > > (or part of tools?) No, it looks like we build it via --enable-guest-agent, and --enable-tools is not checked. thanks -- PMM
On 12/19/22 12:35, Philippe Mathieu-Daudé wrote: > On 16/12/22 20:07, Helge Deller wrote: >> Reduce amount of compiled code and installed binaries if just the qemu >> utilities such as qemu-img, qemu-io and qemu-nbd have to be built. This >> helps to make those tools easier available on hosts where qemu-system or >> qemu-user isn't supported. >> >> Reason for this patch is that qemu fail to build on debian for some >> seconday non-release architectures (e.g. hppa, sh4, ia64), as can be >> seen here: >> https://buildd.debian.org/status/package.php?p=qemu&suite=sid >> This patch helps to clean up the build so that these tools >> can be provided on those platforms in future. >> >> Signed-off-by: Helge Deller <deller@gmx.de> > > >> index fbdb442fdf..4a499db441 100644 >> --- a/qapi/meson.build >> +++ b/qapi/meson.build >> @@ -51,12 +51,12 @@ qapi_all_modules = [ >> 'transaction', >> 'virtio', >> 'yank', >> + 'qdev', >> ] >> if have_system >> qapi_all_modules += [ >> 'acpi', >> 'audio', >> - 'qdev', >> 'pci', >> 'rdma', >> 'rocker', > > Why do you want qdev out of sysemu? I just moved it some lines below sysemu. Helge
Helge Deller <deller@gmx.de> writes: > Hi Paolo, > > On 12/17/22 14:28, Paolo Bonzini wrote: >> On 12/16/22 20:07, Helge Deller wrote: >>> @@ -3581,7 +3581,7 @@ subdir('qga') >>> >>> # Don't build qemu-keymap if xkbcommon is not explicitly enabled >>> # when we don't build tools or system >>> -if xkbcommon.found() >>> +if xkbcommon.found() and have_system >>> # used for the update-keymaps target, so include rules even if !have_tools >>> qemu_keymap = executable('qemu-keymap', files('qemu-keymap.c', 'ui/input-keymap.c') + genh, >>> dependencies: [qemuutil, xkbcommon], install: have_tools) >>> @@ -3596,7 +3596,9 @@ if have_tools >>> dependencies: [blockdev, qemuutil, gnutls, selinux], >>> install: true) >>> >>> - subdir('storage-daemon') >>> + if have_system >>> + subdir('storage-daemon') >>> + endif >>> subdir('contrib/rdmacm-mux') >>> subdir('contrib/elf2dmp') >>> >>> @@ -3611,7 +3613,7 @@ if have_tools >>> subdir('contrib/vhost-user-scsi') >>> endif >>> >>> - if targetos == 'linux' >>> + if targetos == 'linux' and have_system >>> executable('qemu-bridge-helper', files('qemu-bridge-helper.c'), >>> dependencies: [qemuutil, libcap_ng], >>> install: true, >>> diff --git a/tools/meson.build b/tools/meson.build >>> index 10eb3a043f..740d572a94 100644 >>> --- a/tools/meson.build >>> +++ b/tools/meson.build >>> @@ -5,7 +5,7 @@ have_virtiofsd = get_option('virtiofsd') \ >>> error_message: 'virtiofsd requires libcap-ng-devel and seccomp-devel') \ >>> .require(have_vhost_user, >>> error_message: 'virtiofsd needs vhost-user-support') \ >>> - .disable_auto_if(not have_tools and not have_system) \ >>> + .disable_auto_if(not have_system) \ >>> .allowed() >>> >>> if have_virtiofsd >>> >> >> These are wrong. qemu-bridge-helper, virtiofsd, qemu-storage-daemon >> and qemu-keymap *are* tools; if they fail to build due to any >> dependencies, or due to other compilation issues, you need to add >> tests to meson.build and check for the cause of the issues. > > No doubt, those are *tools*. > But aren't those only required when you run system- and/or user-emulation? > > Looking at the packaging of qemu in debian: > > qemu-system-common debian package consists of thse *tools*: > qemu-bridge-helper, vhost-user-gpu, virtfs-proxy-helper, virtiofsd Well technically vhost-user-gpu and virtiofsd are usable (or should be) without QEMU as they are vhost-user backends and could be used with other VMMs that support vhost-user (kvm-tool, crosvm, xen-vhost-frontend). Not withstanding that virtiofsd is now a legacy binary as the production backend for vhost-user virtio-fs is the rust rewrite: https://gitlab.com/virtio-fs/virtiofsd > > qemu-utils debian package consists of the *utilities*: > qemu-img, qemu-io, qemu-nbd > > IMHO this categorization makes sense. > My patch was targetting at making "qemu-utils" possible to build > and that's why I think the tools you mention should depend on "have_system". > >> The rest is okay. > > Ok, thanks! > > Helge
On 12/19/22 12:52, Peter Maydell wrote: > On Mon, 19 Dec 2022 at 11:40, Philippe Mathieu-Daudé <philmd@linaro.org> wrote: >> >> On 19/12/22 12:31, Peter Maydell wrote: >>> On Mon, 19 Dec 2022 at 11:22, Helge Deller <deller@gmx.de> wrote: >>>> >>>> Hi Paolo, >>>> >>>> On 12/17/22 14:28, Paolo Bonzini wrote: >>>>> These are wrong. qemu-bridge-helper, virtiofsd, qemu-storage-daemon >>>>> and qemu-keymap *are* tools; if they fail to build due to any >>>>> dependencies, or due to other compilation issues, you need to add >>>>> tests to meson.build and check for the cause of the issues. >>>> >>>> No doubt, those are *tools*. >>>> But aren't those only required when you run system- and/or user-emulation? >>>> >>>> Looking at the packaging of qemu in debian: >>>> >>>> qemu-system-common debian package consists of thse *tools*: >>>> qemu-bridge-helper, vhost-user-gpu, virtfs-proxy-helper, virtiofsd >>>> >>>> qemu-utils debian package consists of the *utilities*: >>>> qemu-img, qemu-io, qemu-nbd >>>> >>>> IMHO this categorization makes sense. >>> >>> Possibly, but it's not the categorization we use upstream, >>> which splits our binaries into three groups: >>> * system-emulation binaries (qemu-system-arm, etc) >> >> Subcategory: >> >> * helpers (required to use system-emulation binaries), >> apparently provided by 'qemu-system-common' on Debian >> -- except virtiofsd which is not a helper -- > > No, I don't think this is a subcategory. We provide > --enable-system > --enable-user > --enable-tools > but there is no > --enable-helper > and qemu-bridge-helper, etc are built via --enable-tools. > >>> (I think the guest-agent may be a fourth group.) >>> ... > No, it looks like we build it via --enable-guest-agent, > and --enable-tools is not checked. Given that info, would it then make sense to keep as is: --enable-system --enable-user --enable-tools -> qemu-bridge-helper, vhost-user-gpu, virtfs-proxy-helper, virtiofsd --enable-guest-agent -> guest agents (option is there already, but not used) and additonally add: --enable-utils -> qemu-img, qemu-io, qemu-nbd This would leave the helpers in --enable-tools. Helge
20.12.2022 23:56, Helge Deller wrote: .. > Given that info, would it then make sense to keep as is: > --enable-system > --enable-user > --enable-tools -> qemu-bridge-helper, vhost-user-gpu, virtfs-proxy-helper, virtiofsd > --enable-guest-agent -> guest agents (option is there already, but not used) > and additonally add: > --enable-utils -> qemu-img, qemu-io, qemu-nbd tools and utils is confusing, it smells like it's the same thing. I understand that in theory, eg virtiofsd can be used without qemu, with some other software, but in practice there's no such software, and I don't think it will emerge in a (near) future. All the "tools" listed above are system-mode helpers really, this is why I package them in qemu-SYSTEM-common in Debian. They're not very useful for now without some of qemu-system-xx. To my view, these should be part of --enable-system, at least for now. Maybe with a separate --enable-system-helpers to turn them off if needed but I don't think it's necessary. The new "utils" category above actually *is* useful by its own, especially qemu-nbd, for example to access .qcow2 images from the host OS. This is what eg Redhat is shipping in qemu-io package. And these are good to have without --enable-system. /mjt
On 12/21/22 08:49, Michael Tokarev wrote: > 20.12.2022 23:56, Helge Deller wrote: > .. >> Given that info, would it then make sense to keep as is: >> --enable-system >> --enable-user >> --enable-tools -> qemu-bridge-helper, vhost-user-gpu, virtfs-proxy-helper, virtiofsd >> --enable-guest-agent -> guest agents (option is there already, but not used) >> and additonally add: >> --enable-utils -> qemu-img, qemu-io, qemu-nbd > > tools and utils is confusing, it smells like it's the same thing. > > I understand that in theory, eg virtiofsd can be used without qemu, with some > other software, but in practice there's no such software, and I don't think > it will emerge in a (near) future. All the "tools" listed above are system-mode > helpers really, this is why I package them in qemu-SYSTEM-common in Debian. > They're not very useful for now without some of qemu-system-xx. To my view, > these should be part of --enable-system, at least for now. Maybe with a > separate --enable-system-helpers to turn them off if needed but I don't > think it's necessary. > > The new "utils" category above actually *is* useful by its own, especially > qemu-nbd, for example to access .qcow2 images from the host OS. This is what > eg Redhat is shipping in qemu-io package. And these are good to have without > --enable-system. Michael, please note, that the patch I initially sent in this thread is *exactly* doing what you summarize here. Helge
diff --git a/docs/meson.build b/docs/meson.build index 9136fed3b7..cfbde168b7 100644 --- a/docs/meson.build +++ b/docs/meson.build @@ -49,7 +49,7 @@ if build_docs 'qemu-trace-stap.1': (stap.found() ? 'man1' : ''), 'virtfs-proxy-helper.1': (have_virtfs_proxy_helper ? 'man1' : ''), 'virtiofsd.1': (have_virtiofsd ? 'man1' : ''), - 'qemu.1': 'man1', + 'qemu.1': (have_system ? 'man1' : ''), 'qemu-block-drivers.7': 'man7', 'qemu-cpu-models.7': 'man7' } diff --git a/meson.build b/meson.build index 5c6b5a1c75..fe4c9c83bb 100644 --- a/meson.build +++ b/meson.build @@ -3021,7 +3021,6 @@ subdir('util') subdir('qom') subdir('authz') subdir('crypto') -subdir('ui') subdir('hw') subdir('gdbstub') @@ -3060,9 +3059,10 @@ if have_system or have_user arguments: ['@INPUT@', '@EXTRA_ARGS@', '-o', '@OUTPUT@']) subdir('libdecnumber') subdir('target') + subdir('ui') + subdir('audio') endif -subdir('audio') subdir('io') subdir('chardev') subdir('fsdev') @@ -3581,7 +3581,7 @@ subdir('qga') # Don't build qemu-keymap if xkbcommon is not explicitly enabled # when we don't build tools or system -if xkbcommon.found() +if xkbcommon.found() and have_system # used for the update-keymaps target, so include rules even if !have_tools qemu_keymap = executable('qemu-keymap', files('qemu-keymap.c', 'ui/input-keymap.c') + genh, dependencies: [qemuutil, xkbcommon], install: have_tools) @@ -3596,7 +3596,9 @@ if have_tools dependencies: [blockdev, qemuutil, gnutls, selinux], install: true) - subdir('storage-daemon') + if have_system + subdir('storage-daemon') + endif subdir('contrib/rdmacm-mux') subdir('contrib/elf2dmp') @@ -3611,7 +3613,7 @@ if have_tools subdir('contrib/vhost-user-scsi') endif - if targetos == 'linux' + if targetos == 'linux' and have_system executable('qemu-bridge-helper', files('qemu-bridge-helper.c'), dependencies: [qemuutil, libcap_ng], install: true, diff --git a/qapi/meson.build b/qapi/meson.build index fbdb442fdf..4a499db441 100644 --- a/qapi/meson.build +++ b/qapi/meson.build @@ -51,12 +51,12 @@ qapi_all_modules = [ 'transaction', 'virtio', 'yank', + 'qdev', ] if have_system qapi_all_modules += [ 'acpi', 'audio', - 'qdev', 'pci', 'rdma', 'rocker', diff --git a/tests/meson.build b/tests/meson.build index 8e318ec513..a63a7de9f0 100644 --- a/tests/meson.build +++ b/tests/meson.build @@ -1,5 +1,7 @@ subdir('bench') -subdir('qemu-iotests') +if have_system + subdir('qemu-iotests') +endif test_qapi_outputs = [ 'qapi-builtin-types.c', diff --git a/tools/meson.build b/tools/meson.build index 10eb3a043f..740d572a94 100644 --- a/tools/meson.build +++ b/tools/meson.build @@ -5,7 +5,7 @@ have_virtiofsd = get_option('virtiofsd') \ error_message: 'virtiofsd requires libcap-ng-devel and seccomp-devel') \ .require(have_vhost_user, error_message: 'virtiofsd needs vhost-user-support') \ - .disable_auto_if(not have_tools and not have_system) \ + .disable_auto_if(not have_system) \ .allowed() if have_virtiofsd
Reduce amount of compiled code and installed binaries if just the qemu utilities such as qemu-img, qemu-io and qemu-nbd have to be built. This helps to make those tools easier available on hosts where qemu-system or qemu-user isn't supported. Reason for this patch is that qemu fail to build on debian for some seconday non-release architectures (e.g. hppa, sh4, ia64), as can be seen here: https://buildd.debian.org/status/package.php?p=qemu&suite=sid This patch helps to clean up the build so that these tools can be provided on those platforms in future. Signed-off-by: Helge Deller <deller@gmx.de>