qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]