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

[Claudio Fontana]

On 7/21/21 12:47 PM, Claudio Fontana wrote:
> 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?


Before this, though, the KConfig stuff should be all-ok for ARM and possibly 
other archs, I am not sure where we are there..

> 
> 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