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