[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QEMU modules improvements objective (Was: Re: [RFC 0/3] Improve modu
Re: QEMU modules improvements objective (Was: Re: [RFC 0/3] Improve module accelerator error message)
Wed, 21 Jul 2021 12:47:41 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
On 7/21/21 12:35 PM, Gerd Hoffmann wrote:
>> Open question to all,
>> why don't we have/add the ability to configure
>> 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,
I generally agree with your use cases as we see it right now from a distro
perspective, I suspect there are more,
especially thinking of modeling, testing/builds etc on the TCG side of things.
I think that eventually we will end up there anyway due to the requirements
being so vastly different for all possible uses of QEMU.
Doing a proper design of this will allow I think to come to the right
conclusions on how to correctly check for accelerators etc,
without creating a one-off solution for each single feature.
KConfig should probably be driving this from day 1 right?
Yeah, it's tough, but I think we would otherwise just drive circles around
this, implement a lot of provisional stuff,
and still end up there sooner or later in my opinion.