Re: [Qemu-devel] QEMU and Kconfig

[Eduardo Habkost]

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