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

[Hannes Reinecke <hare@suse.com>]

On 06/30/2017 07:52 PM, 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.
> 
And what would be totally cool if we could have fragments _per default_.
EG by not having a massive .config, but rather keeping it per directory,
or maybe corresponding in the directory where each Kconfig lives.
That way it would be easier to figure out where this blasted option cam
from, plus one could easily provide (and check!) configurations for
several systems, keeping the common parts intact and modify only the
machine specific ones.

And it would solve the 'keeping the config current' problem, as one
could quite simply identify which configuration will need to be changed
for a Kconfig change, seeing that both will be kept in the same directory.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.com			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)