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: <cb1333e8-0e0b-2e3a-f5e1-553d2722be82@infradead.org>
Date:   Sun, 15 Jan 2023 16:55:55 -0800
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Peter Foley <pefoley2@...oley.com>,
        Jonathan Corbet <corbet@....net>
Cc:     Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH] Documentation: Avoid duplicate Kconfig inclusion



On 1/15/23 16:42, Peter Foley wrote:
> On Sat, Jan 14, 2023 at 8:25 AM Jonathan Corbet <corbet@....net> wrote:
>> The duplicate inclusion does seem worth fixing, but I wonder if you're
>> deleting the right one?  Having the documentation Kconfig under lib
>> seems a bit strange, somehow; Documentation/ is a top-level directory,
>> after all.
> 
> I thought about that.
> Looking at the history, the toplevel inclusion was added in
> b1663d7e3a7961 (2019-06-04), and the lib/Kconfig.debug inclusion was
> added in 75442fb0ccaacd (2020-10-30).
> Given the actual entries in Documentation/Kconfig
> (WARN_MISSING_DOCUMENTS and WARN_ABI_ERRORS), putting them under the
> "Kernel hacking" menu makes sense to me.
> We *could* add a new top-level menu to Documentation/Kconfig, but it
> doesn't really seem like an improvement over having them live in
> Kernel hacking.

Since b1663d7e3a7961 puts the Documentation/Kconfig just after
lib/Kconfig.debug, there's not much difference in its location in a
*config menu, but I would rather see it separated (independent) from
lib/Kconfig.debug because I think that it would make any future changes
easier.

Also, b1663d7e3a7961 came first. :)

-- 
~Randy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ