From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40675) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKPy0-0007rR-1e for qemu-devel@nongnu.org; Wed, 07 Nov 2018 10:42:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gKPxw-0000oF-37 for qemu-devel@nongnu.org; Wed, 07 Nov 2018 10:42:04 -0500 Received: from mga11.intel.com ([192.55.52.93]:21113) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gKPxv-0000jK-Pg for qemu-devel@nongnu.org; Wed, 07 Nov 2018 10:41:59 -0500 Date: Wed, 7 Nov 2018 16:41:14 +0100 From: Samuel Ortiz Message-ID: <20181107154114.GC27585@caravaggio> References: <20180924092120.GA30163@caravaggio> <7c2b477e-bdac-c887-2510-82fe04acdcfe@redhat.com> <87b22690-e39c-3b46-dcb4-f6abc3213142@redhat.com> <41ceda53-467e-32a1-8fa6-13f0f9c08ad1@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] QEMU and Kconfig List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , Thomas Huth , QEMU Developers , "Zhong, Yang" 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.