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: Thomas Huth
Subject: Re: [Qemu-devel] QEMU and Kconfig
Date: Wed, 7 Nov 2018 20:30:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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.

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 ;-)

>> It would be used to generate config-devices.mak, instead of
>> scripts/make_device_config.sh.  My branch already had some Makefile
>> integration.
>>
>>> - From a user's build perspective, there would be no noticeable
>>>   difference, ./configure && make. Internally, both steps will consume
>>>   the *.mak files generated by minikconf.
>>
>> Right.  The only difference is that a user could do "./configure && make
>> randconfig && make" and similar.
> 
> 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?

 Thomas



reply via email to

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