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
