This patchset introduces the modinfo_kconfig aiming for a fine-tune
control of module loading by simply checking Kconfig options during the
compile time, then generates one modinfo-<target>-softmmu.c per target.

The main reason of this change is to fix problems like:
$ ./qemu-system-s390x -nodefaults -display none -accel tcg -M none -device help | head
Failed to open module: /.../hw-display-qxl.so: undefined symbol: vga_ioport_read
Failed to open module: /.../hw-display-virtio-vga.so: undefined symbol: vmstate_vga_common
Failed to open module: /.../hw-display-virtio-vga.so: undefined symbol: vmstate_vga_common
Failed to open module: /.../hw-display-virtio-vga-gl.so: undefined symbol: have_vga
Failed to open module: /.../hw-usb-smartcard.so: undefined symbol: ccid_card_ccid_attach
Failed to open module: /.../hw-usb-redirect.so: undefined symbol: vmstate_usb_device
Failed to open module: /.../hw-usb-host.so: undefined symbol: vmstate_usb_device

With this patch, I run this small script successfuly:
    #!/bin/bash
    pushd ~/suse/virtualization/qemu/build
    for qemu in qemu-system-*
    do
        [[ -f "$qemu" ]] || continue
        res=$(./$qemu -nodefaults -display none -accel tcg -M none -device help 2>&1 | grep "Failed to" > /dev/null; echo $?)
        [[ $res -eq 0 ]] && echo "Error: $qemu"
    done
    popd

Also run 'make check' and 'check-acceptance' without any failures.

v2 -> v3:
 - Renamed module_needs to module_kconfig [Gerd]
 - Reworded the commit message a bit to improve a better understanding [myself]

v1 -> v2:
 - Changed the approach to this problem after suggestions made by Paolo and Gerd.

Thank you!

Jose R. Ziviani (2):
  modules: introduces module_kconfig directive
  modules: generates per-target modinfo

 hw/display/qxl.c                |  1 +
 hw/display/vhost-user-gpu-pci.c |  1 +
 hw/display/vhost-user-gpu.c     |  1 +
 hw/display/vhost-user-vga.c     |  1 +
 hw/display/virtio-gpu-base.c    |  1 +
 hw/display/virtio-gpu-gl.c      |  1 +
 hw/display/virtio-gpu-pci-gl.c  |  1 +
 hw/display/virtio-gpu-pci.c     |  1 +
 hw/display/virtio-gpu.c         |  1 +
 hw/display/virtio-vga-gl.c      |  1 +
 hw/display/virtio-vga.c         |  1 +
 hw/s390x/virtio-ccw-gpu.c       |  1 +
 hw/usb/ccid-card-emulated.c     |  1 +
 hw/usb/ccid-card-passthru.c     |  1 +
 hw/usb/host-libusb.c            |  1 +
 hw/usb/redirect.c               |  1 +
 include/qemu/module.h           | 10 ++++++++
 meson.build                     | 25 +++++++++++++-------
 scripts/modinfo-generate.py     | 42 ++++++++++++++++++++-------------
 19 files changed, 69 insertions(+), 24 deletions(-)

-- 
2.33.0

On Tue, Sep 28, 2021 at 05:46:26PM -0300, Jose R. Ziviani wrote:
> This patchset introduces the modinfo_kconfig aiming for a fine-tune
> control of module loading by simply checking Kconfig options during the
> compile time, then generates one modinfo-<target>-softmmu.c per target.
> 
> The main reason of this change is to fix problems like:
> $ ./qemu-system-s390x -nodefaults -display none -accel tcg -M none -device help | head
> Failed to open module: /.../hw-display-qxl.so: undefined symbol: vga_ioport_read
> Failed to open module: /.../hw-display-virtio-vga.so: undefined symbol: vmstate_vga_common
> Failed to open module: /.../hw-display-virtio-vga.so: undefined symbol: vmstate_vga_common
> Failed to open module: /.../hw-display-virtio-vga-gl.so: undefined symbol: have_vga
> Failed to open module: /.../hw-usb-smartcard.so: undefined symbol: ccid_card_ccid_attach
> Failed to open module: /.../hw-usb-redirect.so: undefined symbol: vmstate_usb_device
> Failed to open module: /.../hw-usb-host.so: undefined symbol: vmstate_usb_device
> 
> With this patch, I run this small script successfuly:
>     #!/bin/bash
>     pushd ~/suse/virtualization/qemu/build
>     for qemu in qemu-system-*
>     do
>         [[ -f "$qemu" ]] || continue
>         res=$(./$qemu -nodefaults -display none -accel tcg -M none -device help 2>&1 | grep "Failed to" > /dev/null; echo $?)
>         [[ $res -eq 0 ]] && echo "Error: $qemu"
>     done
>     popd
> 
> Also run 'make check' and 'check-acceptance' without any failures.

Acked-by: Gerd Hoffmann <kraxel@redhat.com>

take care,
  Gerd

Hello! Sorry for bringing up an old thread, but I'd have a question
about this series.

As far as I can see, the patches were fine, and they were Acked, but
then the series was never committed... Is this correct?

If yes, can it be committed (I'm up for rebasing and resending, if it's
necessary)? If not, would it be possible to know what's missing, so
that we can continue working on it?

The reason I'm asking is that in our (openSUSE) build system, we're
still seeing the failures shown below; so far, we've had some rather
ugly downstream patches to deal with those, but we've recently
discovered they're not only ugly... they're also broken! :-/

I'm not sure if (and if yes why) this seems to be a problem only for
us, but it'd be great to get rid of both the failures and the patches
(assuming that what is implemented in this series is also of general
use, and good for the project... which, AFAIUI, it should be).

Any kind of feedback would be greatly appreciated.

Thanks and Regards

[PS. I've removed Jose, as his SUSE email address is no longer valid]

On Wed, 2021-09-29 at 07:09 +0200, Gerd Hoffmann wrote:
> On Tue, Sep 28, 2021 at 05:46:26PM -0300, Jose R. Ziviani wrote:
> > This patchset introduces the modinfo_kconfig aiming for a fine-tune
> > control of module loading by simply checking Kconfig options during
> > the
> > compile time, then generates one modinfo-<target>-softmmu.c per
> > target.
> > 
> > The main reason of this change is to fix problems like:
> > $ ./qemu-system-s390x -nodefaults -display none -accel tcg -M none
> > -device help | head
> > Failed to open module: /.../hw-display-qxl.so: undefined symbol:
> > vga_ioport_read
> > Failed to open module: /.../hw-display-virtio-vga.so: undefined
> > symbol: vmstate_vga_common
> > Failed to open module: /.../hw-display-virtio-vga.so: undefined
> > symbol: vmstate_vga_common
> > Failed to open module: /.../hw-display-virtio-vga-gl.so: undefined
> > symbol: have_vga
> > Failed to open module: /.../hw-usb-smartcard.so: undefined symbol:
> > ccid_card_ccid_attach
> > Failed to open module: /.../hw-usb-redirect.so: undefined symbol:
> > vmstate_usb_device
> > Failed to open module: /.../hw-usb-host.so: undefined symbol:
> > vmstate_usb_device
> > 
> > With this patch, I run this small script successfuly:
> >     #!/bin/bash
> >     pushd ~/suse/virtualization/qemu/build
> >     for qemu in qemu-system-*
> >     do
> >         [[ -f "$qemu" ]] || continue
> >         res=$(./$qemu -nodefaults -display none -accel tcg -M none
> > -device help 2>&1 | grep "Failed to" > /dev/null; echo $?)
> >         [[ $res -eq 0 ]] && echo "Error: $qemu"
> >     done
> >     popd
> > 
> > Also run 'make check' and 'check-acceptance' without any failures.
> 
> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
> 
> take care,
>   Gerd
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

On Tue, May 24, 2022 at 01:49:41PM +0200, Dario Faggioli wrote:
> Hello! Sorry for bringing up an old thread, but I'd have a question
> about this series.
> 
> As far as I can see, the patches were fine, and they were Acked, but
> then the series was never committed... Is this correct?
> 
> If yes, can it be committed (I'm up for rebasing and resending, if it's
> necessary)? If not, would it be possible to know what's missing, so
> that we can continue working on it?

rebase, run through ci, resend is probably the best way forward.
Don't remember any problems, not sure why it wasn't picked up,
maybe paolo (who does the meson + buildsystem stuff) was just busy
so it fell through the cracks,

take care,
  Gerd

On Wed, 2022-05-25 at 08:32 +0200, Gerd Hoffmann wrote:
> On Tue, May 24, 2022 at 01:49:41PM +0200, Dario Faggioli wrote:
> > Hello! Sorry for bringing up an old thread, but I'd have a question
> > about this series.
> > 
> > As far as I can see, the patches were fine, and they were Acked,
> > but
> > then the series was never committed... Is this correct?
> > 
> > If yes, can it be committed (I'm up for rebasing and resending, if
> > it's
> > necessary)? If not, would it be possible to know what's missing, so
> > that we can continue working on it?
> 
> rebase, run through ci, resend is probably the best way forward.
>
Ok, great, thanks! I'll do all that.

> Don't remember any problems, not sure why it wasn't picked up,
> maybe paolo (who does the meson + buildsystem stuff) was just busy
> so it fell through the cracks,
> 
Sure, and it's fine... It happens, I know it very well. :-)

I hope it's clear, but just in case, I wasn't complaining or anything.
I just wanted to know what we could do about it now, which is exactly
what you just told me. :-D

Thanks and Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)