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  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]
Date:   Wed, 6 Mar 2019 09:35:21 +0000
From:   Mark Rutland <>
To:     Russell King - ARM Linux admin <>
        Lucas Stach <>,
        Peng Hao <>,
        Andy Shevchenko <>,
        Greg Kroah-Hartman <>
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.


Powered by blists - more mailing lists