Re: [Qemu-devel] QEMU and Kconfig

[Paolo Bonzini <pbonzini@redhat.com>]

On 08/11/2018 18:14, Eduardo Habkost wrote:
> 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"?

Something that affects the way

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

I think it would be more confusing if some backends were to use kconfig
and some wouldn't.  We could certainly add something like

config VHOST_NET
    depends on HOST_LINUX
    default y

config SPICE
    depends on HAVE_SPICE_SERVER
    default Y

etc. but I think we agree it's more of a long term idea.

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

Sure, we could do that.  However, right now you cannot have multiple
binaries for a single target, so you couldn't have one single build
include both a "full-blown" and a "reduced" x86 target.  Therefore,
including e.g. SLIRP in qemu-system-arm but not in qemu-system-x86_64
does not seem too interesting to me.  It would be different if you could
build qemu-system-arm, qemu-system-x86_64, qemu-system-x86_64-lite, etc.

Paolo

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