Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     Masahiro Yamada <masahiroy@kernel.org>
CC:     <linux-kbuild@vger.kernel.org>, <linux-kernel@vger.kernel.org>
From:   Qian Cai <quic_qiancai@quicinc.com>
Subject: Introduce "make debugconfig"
Message-ID: <962c0565-89a3-c6d2-37e0-a93c8c753d57@quicinc.com>
Date:   Thu, 28 Oct 2021 09:32:51 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi there, some general debugging features like kmemleak, KASAN, lockdep,

UBSAN etc help fix many viruses like a microscope. On the other hand, those
 features are scatter around and mixed up with more situational debugging
 options making them difficult to consume properly.


Since I have been deal with those options on a daily basis for the last

a few years and accumulated the knowledge of their pros and cons, I am

thinking about to create an initial "make debugconfig" target, so that
it could amplify the general debugging/testing efforts and help
establish sensitive default values for those options across the broad.


The idea is to have a debugconfig inside kernel/configs/ and update
scripts/kconfig/Makefile and Documentation/admin-guide/README.rst
accordingly. I am still trying to figure out a few implementation
details like how to convert an existing .config to debugconfig, but want
to gather some feedback before I dive in too deep.