Linux-CIFS Archive on
 help / color / Atom feed
From: "Theodore Y. Ts'o" <>
To: "Pali Rohár" <>
Cc: Jan Kara <>,,,,,
	Alexander Viro <>,
	Luis de Bethencourt <>,
	Salah Triki <>,
	Steve French <>,
	OGAWA Hirofumi <>,
	Greg Kroah-Hartman <>,
	Thomas Gleixner <>,
	David Sterba <>,
	Dave Kleikamp <>,
	Anton Altaparmakov <>, Jan Kara <>,
	Eric Sandeen <>,
	Namjae Jeon <>, Pavel Machek <>,
	Christoph Hellwig <>
Subject: Re: Unification of filesystem encoding options
Date: Tue, 7 Jan 2020 15:03:01 -0500
Message-ID: <> (raw)
In-Reply-To: <20200107173842.ciskn4ahuhiklycm@pali>

On Tue, Jan 07, 2020 at 06:38:42PM +0100, Pali Rohár wrote:
> Adding support for case-insensitivity into UTF-8 NLS encoding would mean
> to create completely new kernel NLS API (which would support variable
> length encodings) and rewrite all NLS filesystems to use this new API.
> Also all existing NLS encodings would be needed to port into this new
> API.
> It is really something which have a value? Just because of UTF-8?
> For me it looks like better option would be to remove UTF-8 NLS encoding
> as it is broken. Some filesystems already do not use NLS API for their
> UTF-8 support (e.g. vfat, udf or newly prepared exfat). And others could
> be modified/extended/fixed in similar way.

You didn't mention ext4 and f2fs, which is using the Unicode code in
fs/unicode for its case-folding and normalization support.  Ext4 and
f2fs only supports utf-8, so using the NLS API would have added no
value --- and it as you pointed out, the NLS API doesn't support
variable length encoding anyway.  In contrast the fs/unicode functions
have support for full Unicode case folding and normalization, and
currently has the latest Unicode 12.1 tables (released May 2019).

What I'd suggest is to create a new API, enhancing the functions in
fs/unicode, to support those file systems that need to deal with
UTF-16 and UTF-32 for their on-disk directory format, and that we
assume that for the most part, userspace *will* be using a UTF-8
encoding for the user<->kernel interface.  We can keep the existing
NLS interface and mount options for legacy support, but in my opinion
it's not worth the effort to try to do anything else.

					- Ted

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-02 21:18 Pali Rohár
2020-01-07 13:32 ` Jan Kara
2020-01-07 17:38   ` Pali Rohár
2020-01-07 20:03     ` Theodore Y. Ts'o [this message]
2020-01-07 20:37       ` Pali Rohár
2020-01-08  7:13         ` OGAWA Hirofumi
2020-01-08  7:00     ` OGAWA Hirofumi

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-CIFS Archive on

Archives are clonable:
	git clone --mirror linux-cifs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-cifs linux-cifs/ \
	public-inbox-index linux-cifs

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone