[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QEMU modules improvements objective (Was: Re: [RFC 0/3] Improve modu
From: |
Gerd Hoffmann |
Subject: |
Re: QEMU modules improvements objective (Was: Re: [RFC 0/3] Improve module accelerator error message) |
Date: |
Wed, 21 Jul 2021 12:35:28 +0200 |
Hi,
> Open question to all,
>
> why don't we have/add the ability to configure
>
> CONFIG_XXX=m
>
> for all potentially modular pieces?
>
> It should be possible to say, I want to build the storage plugins as modules,
> TCG I would like it built-in, and KVM as a module,
> or any combination of these.
>
> The most useful combination I see for virtualization use of qemu is with TCG
> as a module (M), KVM as built-in (Y), and various other optional pieces as
> modules (M).
Surely doable. Comes with maintenance and testing cost though.
For example you'll get new kinds of dependencies: when building foo as
module stuff depending on foo must be built modular too (spice-core=m +
qxl=y doesn't work).
I see mainly two use cases:
(1) distro builds. Those would enable most features and also modules
for fine-grained rpm/deb packaging.
(2) builds for specific use cases. Those would disable modules and
just use CONFIG_FOO=n for things they don't need.
Being able to set CONFIG_FOO=y for features used in >90% of the use
cases (kvm, some virtio devices come to mind) might be useful for (1).
Distros do that with linux kernel builds too (Fedora kernel has
CONFIG_SATA_AHCI=y, CONFIG_USB_XHCI_PCI=y, ...).
But the question is: Are the benefits worth the effort?
take care,
Gerd