linux-kernel - Q: Kconfig: 'If unsure, say N'

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-next>] [day] [month] [year] [list]

Message-Id: <D5GVI1Q30BTS.1ZVQ4YC4OJYEL@cknow.org>
Date: Fri, 08 Nov 2024 15:39:30 +0100
From: "Diederik de Haas" <didi.debian@...ow.org>
To: <linux-kernel@...r.kernel.org>
Cc: <linux-rockchip@...ts.infradead.org>, "Shawn Lin"
 <shawn.lin@...k-chips.com>, "Sudeep Holla" <sudeep.holla@....com>
Subject: Q: Kconfig: 'If unsure, say N'

Hi,

In quite a number of Kconfig help text entries I see this:
"If unsure, say N."

But that raises the question: How can I be sure?

To me, this comes across as that the person who implemented the feature
recommends *against* using it, unless you think you know better then the
person who implemented it. Which is quite a high bar.

IIRC I did come across an entry which paraphrased said:
"This module can be useful in situation Y, but you run a real risk of
physically damaging your board when you use it.
So normally you REALLY should not enable this, but if you still need it
then the functionality is implemented in this module.

If unsure, say N."

Which is an excellent reason not to enable it ;-)
Moreover, it specifies when you can/should go against the advise and
tells you what the risk is if you do.

But the vast majority just says "If unsure, say N."

The problem is that I'd need a better justification to enable (as 'y' or
'm') a module then "Based on (the rest of) the Help text, this looks
really useful".

Not to discuss these specifically, but just for illustration:
``drivers/firmware/arm_scmi/transports/Kconfig`` has this
option: ``ARM_SCMI_TRANSPORT_SMC_ATOMIC_ENABLE``
which IIUC enables an *optional* feature for an atomic transaction.

Which sounds useful and harmless, yet ... "If unsure, say N."

And the trigger which caused me to actually write this email was
"scsi: ufs: rockchip: initial support for UFS"
which I interpret as: if you want to use UFS on Rockchip based devices,
you should enable this. But ... "If unsure, say N."

So it would be really helpful if the Kconfig help text:
1) did not say "If unsure, say N."
2) If the recommendation is indeed to NOT enable it ('normally'),
   specify why and under what situation/condition you can go against the
   maintainer/implementers recommendation

Cheers,
  Diederik

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)