[Top][All Lists]

[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: Claudio Fontana
Subject: Re: QEMU modules improvements objective (Was: Re: [RFC 0/3] Improve module accelerator error message)
Date: Wed, 21 Jul 2021 12:50:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

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

reply via email to

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