Re: QEMU modules improvements objective (Was: Re: [RFC 0/3] Improve module accelerator error message)

[Claudio Fontana]

On 7/21/21 12:35 PM, Gerd Hoffmann wrote:
>   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
> 

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.

Ciao,

CLaudio