linux-kernel - Re: [PATCH v2] configs: Introduce debug.config for CI-like setup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e0301a5f-a2c7-eedb-90b1-1d6d631fcc47@quicinc.com>
Date:   Fri, 29 Oct 2021 09:57:31 -0400
From:   Qian Cai <quic_qiancai@...cinc.com>
To:     Daniel Thompson <daniel.thompson@...aro.org>
CC:     Andrew Morton <akpm@...ux-foundation.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        <linux-kbuild@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] configs: Introduce debug.config for CI-like setup

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.

>> +# 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. 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