Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Darren Hart <dvhart@infradead.org>]

On Fri, Jun 30, 2017 at 10:52:01AM -0700, Darren Hart wrote:
> On Tue, Jun 27, 2017 at 10:18:04AM -0700, Linus Torvalds wrote:
> > On Tue, Jun 27, 2017 at 6:58 AM, Sergey Senozhatsky
> > <sergey.senozhatsky.work@gmail.com> wrote:
> > >
> > > am I the only one who struggle with the Kconfig sometimes?
> > 
> > I hate our Kconfig. It's my least favorite part of the kernel. It asks
> > questions about insane things that nobody can know the answer to.
> > 
> > Taking a distro default config and doing"make localmodconfig" is what
> > I end up doing on new machines, and it has all kinds of suckage too.
> > 
> > I don't have a solution to it. But I think part of the solution would
> > be for us to have various "sane minimal requirement" Kconfig
> > fragments, and trhe ability to feed them incrementally, so that people
> > can build up a sane Kconfig from "I want this".
> 
> This was, in part, the intent behind the configuration fragments and the
> merge_config.sh script. I use this with the x86 platform drivers:
> 
> $ make defconfig pdx86.config
> 
> But I have to generate, also scripted, the pdx86.config by scraping the
> Kconfig file. The kvm_guest.config. There are other things I would like
> to see subconfigs for, like "efi.config" - but I wasn't sure what the
> current view on such things were. I'm glad to know I'm not along in my
> frustration with the overly granular nature of Kconfig.
> 
> The problem with this model of course is keeping the config fragments
> current with Kconfig changes. The mergeconfig script does call out
> problems with specified config options. We can address this with
> a configcheck target or similar which would audit the config fragments
> to ensure they are kept in sync with the Kconfig files.
> 
> ...
> 
> > 
> > And note that none of this is about technoliogy, and SAT solvers and
> > resolving the KConfig depdendencies that some techie people love
> > talking about. It's all about "what if we just had some kconfig
> > fragments to enable some commonly used stuff" (where "commonly used"
> > is obviously architecture dependent, but also target-dependent - a
> > "simpleconfig" for a PC workstation kind of config is very different
> > from a "simpleconfig" for a server or some ARM embedded thing).
> > 
> 
> It sounds like the existing config fragment mechanism is sufficient for
> what you describe and what we need to do is create these fragments.
> 
> One thing that would be nice is if we could have fragment nesting so you
> could create your "simpleconfig" which in turn includes a few of the
> more specific config fragments.

We could also have a simple config view for the make *config UIs which
would enumerate all the config fragments, perhaps with some meta data so
they are self descriptive, and then it runs upon save:

$ make minconfig foo.config bar.config kvm.config efi.config dell.config

-- 
Darren Hart
VMware Open Source Technology Center