[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220515044926.l2dg2jh7i3ujkmsc@riteshh-domain>
Date: Sun, 15 May 2022 10:19:26 +0530
From: Ritesh Harjani <ritesh.list@...il.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-ext4@...r.kernel.org, linux-fscrypt@...r.kernel.org,
Theodore Ts'o <tytso@....edu>, Jan Kara <jack@...e.cz>
Subject: Re: [PATCHv2 2/3] ext4: Cleanup function defs from ext4.h into
crypto.c
On 22/05/14 08:40PM, Eric Biggers wrote:
> On Sat, May 14, 2022 at 10:52:47PM +0530, Ritesh Harjani wrote:
> > diff --git a/fs/ext4/crypto.c b/fs/ext4/crypto.c
> [...]
> > +int ext4_fname_setup_filename(struct inode *dir, const struct qstr *iname,
> > + int lookup, struct ext4_filename *fname)
> > +{
> [...]
> > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> [...]
> > +int ext4_fname_setup_filename(struct inode *dir,
> > + const struct qstr *iname, int lookup,
> > + struct ext4_filename *fname);
>
> Very minor nit: the above declaration can be formatted on 2 lines, the same as
> the definition.
Thanks for spotting. I will make the change.
>
> Otherwise this patch looks fine. I think that filename handling in ext4 in
> general is still greatly in need of some cleanups, considering that ext4 now has
> to support all combinations of encryption and casefolding. f2fs does it in a
> somewhat cleaner way, IMO. And it's possible that would lead us down a slightly
> different path. But this is an improvement for now.
Some examples please which you posibly have in mind which should help in
cleanup ext4's filename handling code. I can get back to it after completing
some other items in my todo list.
>
> Reviewed-by: Eric Biggers <ebiggers@...gle.com>
Thanks!!
-ritesh
Powered by blists - more mailing lists