linux-kernel - Re: Smarter Kconfig help

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: <20190306093521.GA50994@lakrids.cambridge.arm.com>
Date:   Wed, 6 Mar 2019 09:35:21 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Lucas Stach <l.stach@...gutronix.de>,
        Peng Hao <peng.hao2@....com.cn>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: Smarter Kconfig help

On Tue, Mar 05, 2019 at 05:31:12PM +0000, Russell King - ARM Linux admin wrote:
> Guys,

Hi Russell,

> We need to be smarter when writing Kconfig help.  I'm just going
> through updating my build trees with the results of 5.0 development,
> and a number of the help texts are next to useless.  For example,
> 
> PVPANIC - is this something that should be enabled for a host or
> guest kernel?  Answer: you have to read the driver code to find out.

When I looked at the help text:

    This driver provides support for the pvpanic device.  pvpanic is
    a paravirtualized device provided by QEMU; it lets a virtual machine
    (guest) communicate panic events to the host.

... it seemed clear to me that this was for a guest, given the text says
QEMU provides the device. I guess you read that as meaning QEMU asks the
host kernel to provide the device to the guest?

Do you have a suggestion for how to word that unambiguously?

> IMX_IRQSTEER - which i.MX SoCs does this apply to?  The help text
> just says:
> 
>   "Support for the i.MX IRQSTEER interrupt multiplexer/remapper."
> 
> which doesn't say which SoCs this should be enabled for - it turns
> out that grepping for the driver's DT compatible string, none of
> the 32-bit ARM cores have support for this, yet we still default
> it to enabled there.  It seems the help text should at the very
> least tell the user that this is not applicable to i.MX SoCs with
> 32-bit ARM cores.
> 
> I'm sure there's many other instances of this... I suspect that
> it's caused by review concentrating mostly on the technical aspects
> of the code and the Kconfig help text just gets forgotten about.

Just to be clear, in general what you want is for Kconfig help to be
clearer about *when* an option is relevant, right?

I'll try to bear that in mind when reviewing in future.

Thanks,
Mark.