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.