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
