From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2F1DD8CC for ; Fri, 30 Jun 2017 17:58:54 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EEE141DB for ; Fri, 30 Jun 2017 17:58:52 +0000 (UTC) Date: Fri, 30 Jun 2017 10:58:50 -0700 From: Darren Hart To: Linus Torvalds Message-ID: <20170630175850.GD26257@fury> References: <20170627135839.GB1886@jagdpanzerIV.localdomain> <20170630175201.GC26257@fury> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170630175201.GC26257@fury> Cc: ksummit , Michal Hocko Subject: Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 > > 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