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: <20241112054623.7zxte2nny7h4st3h@bogus>
Date: Tue, 12 Nov 2024 05:46:23 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Diederik de Haas <didi.debian@...ow.org>
Cc: linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
	Sudeep Holla <sudeep.holla@....com>,
	Shawn Lin <shawn.lin@...k-chips.com>
Subject: Re: Q: Kconfig: 'If unsure, say N'

On Fri, Nov 08, 2024 at 03:39:30PM +0100, Diederik de Haas wrote:
> 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.
>

If you don't know about the feature and it is not having any user-interface
why do you want to enable it. You must understand the feature to enable it
and use it IMO.

> 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".
>

You seem to contradict yourself here. If you have understood the help
text and think it is useful, it seems to me as an indication that you
are not unsure really. So you can enable it if you want TBH.

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

"If you want the SCMI SMC based transport to operate in atomic
mode, avoiding any kind of sleeping behaviour for selected
transactions on the TX path, answer Y.

Enabling atomic mode operations allows any SCMI driver using this
transport to optionally ask for atomic SCMI transactions and operate
in atomic context too, at the price of using a number of busy-waiting
primitives all over instead."

So you read the above text, understood and find it useful. You must be
not unsure of this feature then, so what does that text bother you.
It is just a caution to users who are just build and not looked at the
code, or have no idea about the feature or doesn't understand the help
text.

--
Regards,
Sudeep

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ