[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QEMU and Kconfig
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] QEMU and Kconfig |
Date: |
Thu, 8 Nov 2018 16:42:42 -0200 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
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
- Re: [Qemu-devel] QEMU and Kconfig, (continued)
- Re: [Qemu-devel] QEMU and Kconfig, Eduardo Habkost, 2018/11/07
- Re: [Qemu-devel] QEMU and Kconfig, Thomas Huth, 2018/11/07
- Re: [Qemu-devel] QEMU and Kconfig, Paolo Bonzini, 2018/11/08
- Re: [Qemu-devel] QEMU and Kconfig, Thomas Huth, 2018/11/08
- Re: [Qemu-devel] QEMU and Kconfig, Philippe Mathieu-Daudé, 2018/11/08
- Re: [Qemu-devel] QEMU and Kconfig, Paolo Bonzini, 2018/11/08
- Re: [Qemu-devel] QEMU and Kconfig, Eduardo Habkost, 2018/11/08
- Re: [Qemu-devel] QEMU and Kconfig, Paolo Bonzini, 2018/11/08
- Re: [Qemu-devel] QEMU and Kconfig, Eduardo Habkost, 2018/11/08
- Re: [Qemu-devel] QEMU and Kconfig, Paolo Bonzini, 2018/11/08
- Re: [Qemu-devel] QEMU and Kconfig,
Eduardo Habkost <=
- Re: [Qemu-devel] QEMU and Kconfig, Paolo Bonzini, 2018/11/08
- Re: [Qemu-devel] QEMU and Kconfig, Eduardo Habkost, 2018/11/08
- Re: [Qemu-devel] QEMU and Kconfig, Paolo Bonzini, 2018/11/09
- Re: [Qemu-devel] QEMU and Kconfig, Eduardo Habkost, 2018/11/09
- Re: [Qemu-devel] QEMU and Kconfig, Paolo Bonzini, 2018/11/14
- Re: [Qemu-devel] QEMU and Kconfig, Samuel Ortiz, 2018/11/08
Re: [Qemu-devel] QEMU and Kconfig, Philippe Mathieu-Daudé, 2018/11/08