qemu-devel
[Top][All Lists]
Advanced

[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 11:06:48 -0200
User-agent: Mutt/1.9.2 (2017-12-15)

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.

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]