On Thu, Nov 08, 2018 at 06:58:11PM +0100, Paolo Bonzini wrote: > 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. Agreed. > > > 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. Understood. I assumed this would be one of the short-term goals. We can work on that later, then. > > 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. > > > -- Eduardo