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: Samuel Ortiz
Subject: Re: [Qemu-devel] QEMU and Kconfig
Date: Wed, 7 Nov 2018 16:41:14 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

Hi Paolo,

On Thu, Sep 27, 2018 at 10:55:59AM +0200, Paolo Bonzini wrote:
> > What is the syntactic thing in this example which distinguishes
> > "user can toggle this" (ESP_PCI, ARM_VIRT, SUN4M) from "user
> > can't toggle this, it's just an internal thing selected by
> > other nodes" (the rest) ? I'm assuming we'd have some sort
> > of UI thingy that presents the user only with the user-settable
> > options.
> 
> There's no UI, the configuration is still done with default-configs/;
> however the defaults are specified in the Kconfig files, so the
> default-configs/ files are basically empty (they are not yet empty in
> the branch I posted, but that's not by design; it's just one of the
> reasons why the code was never sent for inclusion upstream).
Reviving this thread as we're starting to work on your minkconf
patches. Let me try to summarize what I understand you have in mind:

- Use Kconfig as a language, not the Kconfig tools from the kernel.
- For each folder, have a Kconfig file describing dependencies and
  selections for any machine/feature/device.
- The Kconfig parser would be used to generate the equivalent of what we
  currently have under default-configs/
- 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.

Does that sound accurate to you?

Cheers,
Samuel.




reply via email to

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