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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 04 Feb 2020 23:21:33 -0500
From:   Gabriel Krisman Bertazi <>
To:     Daniel Rosenberg <>
Cc:     "Theodore Ts'o" <>,,
        Jaegeuk Kim <>, Chao Yu <>,,
        Eric Biggers <>,,
        Alexander Viro <>,
        Richard Weinberger <>,,
        Andreas Dilger <>,
        Jonathan Corbet <>,,,,
Subject: Re: [PATCH v6 1/5] unicode: Add standard casefolded d_ops

Daniel Rosenberg <> writes:

> On Sun, Feb 2, 2020 at 5:46 PM Gabriel Krisman Bertazi
> <> wrote:
>> I don't think fs/unicode is the right place for these very specific
>> filesystem functions, just because they happen to use unicode.  It is an
>> encoding library, it doesn't care about dentries, nor should know how to
>> handle them.  It exposes a simple api to manipulate and convert utf8 strings.
>> I saw change was after the desire to not have these functions polluting
>> the VFS hot path, but that has nothing to do with placing them here.
>> Would libfs be better?  or a casefolding library in fs/casefold.c?
>> --
>> Gabriel Krisman Bertazi
> The hash function needs access to utf8ncursor, but apart from that,
> libfs would make sense. utf8ncursor is the only reason I have them
> here. How do you feel about exposing utf8cursor or something similar?


It was designed to be an internal thing, but I'm ok with exposing it.

Gabriel Krisman Bertazi

Powered by blists - more mailing lists