lkml.org 
[lkml]   [2022]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Kconfig: eliminate abnormal characters displayed under menuconfig
On Tue, Aug 02, 2022 at 06:12:33PM +0800, Liu Song wrote:
> From: Liu Song <liusong@linux.alibaba.com>
>
> Use "find ./linux/* | grep Kconfig | xargs file | grep UTF", can find
> files with utf-8 encoded characters, these files will display garbled
> characters in menuconfig, except for characters with special meanings
> that cannot be modified, modify the characters with obvious errors to
> eliminate the wrong display under meunconfig.
>
> Signed-off-by: Liu Song <liusong@linux.alibaba.com>
> Suggested-by: Bjorn Helgaas <helgaas@kernel.org>

I did suggest fixing everything at once. But I think there are
actually two problems here. The first is that some are just wrong,
e.g., drivers/pci/Kconfig using CYRILLIC SMALL LETTER DZE instead of
"s", or net/netfilter/ipvs/Kconfig using NO-BREAK SPACE for no good
reason.

arch/Kconfig looks like it's using RIGHT SINGLE QUOTATION MARK instead
of the basic APOSTROPHE. That one is debatable; I think it's fair to
argue that RIGHT SINGLE QUOTATION MARK would be preferred if rendered
correctly.

The second problem is that I think menuconfig doesn't handle UTF-8
correctly. For example, in a gnome terminal with the default
LC_ALL=en_US.UTF-8, these look fine:

$ grep -A10 MTD_SPI_NOR_USE_4K_SECTORS drivers/mtd/spi-nor/Kconfig
...
64 KiB block instead of 16 × 4 KiB sectors.

$ grep -A1 MTD_NAND_CAFE drivers/mtd/nand/raw/Kconfig
config MTD_NAND_CAFE
tristate "OLPC CAFÉ NAND controller"

But when menuconfig in the same terminal displays that same text, it
looks like "16 ~W 4 KiB sectors" and "OLPC CAF ~I NAND".

On the other hand, gconfig and xconfig do render these correctly. So
I think there's something wrong with UTF-8 in menuconfig, and we
should fix that as well.

Anyway, I'm fine with this patch as far as it goes:

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

> Acked-by: Randy Dunlap <rdunlap@infradead.org>
> Tested-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> arch/Kconfig | 2 +-
> drivers/pci/Kconfig | 2 +-
> net/netfilter/ipvs/Kconfig | 8 ++++----
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 5ea3e38..2462337 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -745,7 +745,7 @@ config CFI_CLANG
> depends on CLANG_VERSION >= 140000
> select KALLSYMS
> help
> - This option enables Clang’s forward-edge Control Flow Integrity
> + This option enables Clang's forward-edge Control Flow Integrity
> (CFI) checking, where the compiler injects a runtime check to each
> indirect function call to ensure the target is a valid function with
> the correct static type. This restricts possible call targets and
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 133c732..8102b78 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -166,7 +166,7 @@ config PCI_P2PDMA
> depends on ZONE_DEVICE
> select GENERIC_ALLOCATOR
> help
> - Enableѕ drivers to do PCI peer-to-peer transactions to and from
> + Enables drivers to do PCI peer-to-peer transactions to and from
> BARs that are exposed in other devices that are the part of
> the hierarchy where peer-to-peer DMA is guaranteed by the PCI
> specification to work (ie. anything below a single PCI bridge).
> diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
> index 271da84..06b9066 100644
> --- a/net/netfilter/ipvs/Kconfig
> +++ b/net/netfilter/ipvs/Kconfig
> @@ -308,10 +308,10 @@ config IP_VS_MH_TAB_INDEX
> stored in a hash table. This table is assigned by a preference
> list of the positions to each destination until all slots in
> the table are filled. The index determines the prime for size of
> - the table as 251, 509, 1021, 2039, 4093, 8191, 16381, 32749,
> - 65521 or 131071. When using weights to allow destinations to
> - receive more connections, the table is assigned an amount
> - proportional to the weights specified. The table needs to be large
> + the table as 251, 509, 1021, 2039, 4093, 8191, 16381, 32749,
> + 65521 or 131071. When using weights to allow destinations to
> + receive more connections, the table is assigned an amount
> + proportional to the weights specified. The table needs to be large
> enough to effectively fit all the destinations multiplied by their
> respective weights.
>
> --
> 1.8.3.1
>

\
 
 \ /
  Last update: 2022-08-09 04:53    [W:0.065 / U:0.980 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site