On Thu, Nov 08, 2018 at 02:42:19PM +0100, Paolo Bonzini wrote: > On 08/11/2018 14:06, Eduardo Habkost wrote: > > On Thu, Nov 08, 2018 at 10:55:21AM +0100, Paolo Bonzini wrote: > >> On 07/11/2018 20:30, Thomas Huth wrote: > >>> On 2018-11-07 20:24, Eduardo Habkost wrote: > >>>> On Wed, Nov 07, 2018 at 06:39:54PM +0100, Paolo Bonzini wrote: > >>>>> On 07/11/2018 16:41, Samuel Ortiz wrote: > >>>>>> - The Kconfig parser would be used to generate the equivalent of what > >>>>>> we > >>>>>> currently have under default-configs/ > >>> > >>> I think we would still have something like default-configs - but there > >>> would only be the bare minimum config switches in there, the rest would > >>> be pulled in by dependencies. > >> > >> Yes, in theory default-configs would end up empty, except for possibly > >> some commented lines to show the "default y" symbols for the target. > >> > >>> We could then also even have multiple config directories: > >>> > >>> ./configs > >>> +-------/default-softmmu > >>> +-------/default-linux-user > >>> +-------/nemu (or lean-kvm or something similar) > >>> +... > >>> > >>> ... just my 0.02 €, feel free to ignore that idea ;-) > >> > >> Yup, one can also think of a configure option like "./configure > >> --with-device-config=configs/nemu/" to pick up the alternative > >> configurations. > >> > >>>> Also, I would like to eventually replace many ./configure options > >>>> with options read from a build configuration file. > >>>> > >>>> Distributions often have huge ./configure command lines in their > >>>> QEMU packages, and they could be replaced by simple build > >>>> configuration files. > >>>> > >>>> Having a mode that requires all build options to be specified > >>>> explicitly (instead of silently picking a default) would be > >>>> useful for distributions, too. > >>> > >>> I think we should maybe not mix host configuration (via ./configure) and > >>> the target configuration (via kconfig), should we? > >> > >> Yeah, the configure command line is a different story. If there are > >> suggestion on how to improve it, great, but let's not conflate it with > >> Kconfig. > > > > I believe we have many ./configure options that are supposed to > > be target configuration. e.g.: --enable-slirp, --eanble-kvm, > > --enable-xen, etc. > > SLIRP is not a target configuration, it's a backend like most other > configure command line options. The accelerators are but (except for > TCG of course) they also depend on the host OS and architecture, which > makes them a bit more complicated than default-configs/ symbols. There > are also things like --enable-vhost-user which affect the creation of > both devices (e.g. vhost-user-scsi-pci) and backends (e.g. the > vhost-user-net backend, which uses a "regular" virtio-net-pci device). >
Keeping in mind that I might be talking about extra challenges we won't address right now (no cart before the horse), I have new questions: Why you say backends are not a target configuration and accelerators are? What's the definition of "target configuration"? Are we explicitly restricting the scope of this work to enabling/disabling device emulation code right now? Why? Why wouldn't we use kconfig to enable/disable simple backends with no host dependency like SLIRP? Don't we want to make backends configurable per binary, too? e.g.: I would expect the default configuration for a NEMU-like binary to disable many backends. > It would surely be possible for configure to call into minikconf to > parse a configuration file and apply dependencies (do we actually have > dependencies across configure options?) or something like that, but > let's not put the cart before the horse... Agreed. -- Eduardo
