From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D257C433FE for ; Fri, 29 Oct 2021 16:19:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 71D9761154 for ; Fri, 29 Oct 2021 16:19:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229826AbhJ2QW1 (ORCPT ); Fri, 29 Oct 2021 12:22:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229607AbhJ2QW0 (ORCPT ); Fri, 29 Oct 2021 12:22:26 -0400 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3AA67C061570 for ; Fri, 29 Oct 2021 09:19:57 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id b12so12509729wrh.4 for ; Fri, 29 Oct 2021 09:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ikgahne8KsmeRHB0JuMt+hCjE+vDKAl9WiAJzz6l2C4=; b=yTNK5OyhTtsrJYojdFQbqgaD5Lw4ruZTav9ekBbwBHX9h657sM0VcG/V7AeKm0fl/l qv5aZKAbHHnJdbpH4+6HwLgfU4cPMG+4oyTiuemnPEt5MbikJ1hcv7y9g+icvZMiv5kQ lej0aEJ97x1tabCM3EI1zJQ6yL4KO1bS4gRM2cl3g646f1EafnrDhcNrZ1QOlaZ3zHfE 1q1otLK4zLVc7kKCSaBYV3PjyncWUpl4/yzzrptxrMDMB+QM0lSwR8T+avlb6iJVnDM4 oTq9zDK6kz3cyJ8e89xDQtDJcN4MBMXRIxoM68NJtqcbN/G4IU3bl29UQ9UPawnduUT5 D4bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ikgahne8KsmeRHB0JuMt+hCjE+vDKAl9WiAJzz6l2C4=; b=ueRfpHTfrI7mpHyJimbJ0tuyPLOtczCHp8IJjNBIWpe49uCs4qv4kMveFoy3BDoYoI 4MZsgAnAjUufHwEhdDl1bqI6nNp98T7qci9U2orYK42qbV+bXWp8kvNFftzJrFMGkyPh Iq1J75jQlgX2z+dwxLUS6vrGt+lmJwqSlcIeDnTQ62m+/EE7qd99wJ9DHrPEAwrvsRC9 3vFpv5pjgXzMSPuzekVCbDLsB0t6wmVo9ZFPoBCG7np7iqZlL/ZOsNBvwJIw6a0o1Fdm AxZ1cFam1jLJUFOFY6WdggAYcG6NkZGWTcSFrs4kLzoYglCV0WwMo19jHAajOHhzEIuC 0zHA== X-Gm-Message-State: AOAM533w1ryNfKCrSwyRl4MeiWUL1GCXR5HPA1Fv/eZr+ijDZNgcPcjS +3/whfvuyZXQ9tHKCAoX70TUWu9xZcB2+qLg X-Google-Smtp-Source: ABdhPJwQTTfPOMqLfiUtj/Hw5Y2Z3mJ4qcKrUU+eQDR3bfPY1QdIkAR6ZxQGOh95l4OIHTzjiAG1BQ== X-Received: by 2002:adf:d1ce:: with SMTP id b14mr15920082wrd.42.1635524395515; Fri, 29 Oct 2021 09:19:55 -0700 (PDT) Received: from maple.lan (cpc141216-aztw34-2-0-cust174.18-1.cable.virginm.net. [80.7.220.175]) by smtp.gmail.com with ESMTPSA id l6sm5320315wmq.17.2021.10.29.09.19.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Oct 2021 09:19:55 -0700 (PDT) Date: Fri, 29 Oct 2021 17:19:52 +0100 From: Daniel Thompson To: Qian Cai Cc: Andrew Morton , Masahiro Yamada , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] configs: Introduce debug.config for CI-like setup Message-ID: <20211029161952.u4g7vutcz3qd57lo@maple.lan> References: <20211029034434.24553-1-quic_qiancai@quicinc.com> <20211029093115.6ychbe56pnebzi43@maple.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 29, 2021 at 09:57:31AM -0400, Qian Cai wrote: > On 10/29/21 5:31 AM, Daniel Thompson wrote: > > Does this config need comments at the top of the file describing its > > "mission"? Put another way, the comments in the description about > > where these config options come from seem too important leave buried > > in the git history. They are important to understanding what it is > > for. > > > > I know this the other configs do not have big header comments. However > > the existing configs are closer to self-describing. debug.config simply does not explain what the file does in the way xen.config can! People > > will surely want to add their "favourite" debug options[1] and those > > contributors would benefit from clues on what the configs here are > > intended for. > > Daniel, (small world, isn't it? Enjoyed your OpenEmbedded lessons in the > past.), That's a good point. I personally got used to "git log". I'll > add some comments there. Hello again. In this case the small world comes about because "debug" is of the keywords I use to filter LKML ;-) > >> +# Keep alphabetically sorted. > > > > This results in 119 line file that is more-or-less impossible to > > comment. It alphabetic really the best way to maintain something > > containing so much subjective judgement? > > I thought about ordering those in different subject groups, but then > realized it might be an overkill for an only one-hundred line file. Most > of the options would have a prefix like _LOCKDEP_, _KMEMLEAK_ etc, so > they are subject-related close together even sorted alphabetically. My feedback came about because, in alphabetic form, it is not easy to see which ftrace tracers are enabled (because they are named CONFIG__TRACER they appear all over the place). > I don't really have a strong option on this matter though. We could > organize it like in Kconfig sections if people like that way better > although it could have a potential overhead to sync with future > Kconfig.debug in the future as their places and names change from time > to time. > > # printk and dmesg options > # Compile-time checks and compiler options > # Generic Kernel Debugging Instruments > # Memory Debugging > # Scheduler Debugging > # Lock Debugging (spinlocks, mutexes, etc...) > # Debug kernel data structures > # RCU Debugging Personally I'd favour this. It really depends on how often it is read/changed by uesrs rather than just consumed by the build system. Personally I think this will be read quite often. Daniel.