[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU and Kconfig

From: Paolo Bonzini
Subject: Re: [Qemu-devel] QEMU and Kconfig
Date: Thu, 13 Dec 2018 14:27:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 13/12/18 12:50, Yang Zhong wrote:
> Hello Paolo and all,
> The Kconfig has been completed the porting from your repo and
> now i can sucessfully build x86_64-softmmu binary. But there
> are still some issues:
>    1) Only support x86_64 platform.
>       Other platform, especially for ARM platforms, it's hard for me to 
> define 
>       detailed boards like pc or q35 in x86.

No problem, Philippe can look at least at ARM and MIPS.

>    2) Only support "defconfig". 
>       "randconfig" build has some issues, which are mostly related with 
> CONFIG* in Kconfig.host, 
>       some CONFIG* has different setting value in config-host.mak and 
> %/config-device.mak. like
>       CONFIG_OPENGL=y in %/config-device.mak and CONFIG_OPENGL=n in 
> config-host.mak, which result
>       in build failure.

This is probably a bug or missing features in minikconf; values from
config-host.mak and config-target.mak should not be included in

> The current configure and build command are almost same with before and if we 
> want to disable or enable
> some features, like "tcg", we still need add "--enable/--disable-tcg" in 
> configure command line. If we want
> to disable one emulation device, we can disable this in related Kconfig file 
> in hw/ directory.

Yes, this is expected.

> There are still some left issues
>    a) How to replace the CONFIG* in configure, Some CONFIG* need some logic 
> to generate, 
>       those are hard to input this CONFIG* in Kconfig.host or Kconfig* file.
>    b) The CONFIG* in %/config-target.mak file, this is still related with 
> configure. 
>    c) If a) and b) can be fixed, randconfig is not critical issue.
> I will send RFC patches to QEMU community and please all give some comments. 
> many thanks!

Great, this way people can experiment it and we can finalize the design
before continuing the work.



reply via email to

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