[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200116105108.GA16924@lst.de>
Date: Thu, 16 Jan 2020 11:51:08 +0100
From: Christoph Hellwig <hch@....de>
To: Pali Rohár <pali.rohar@...il.com>
Cc: Namjae Jeon <namjae.jeon@...sung.com>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
gregkh@...uxfoundation.org, valdis.kletnieks@...edu, hch@....de,
sj1557.seo@...sung.com, linkinjeon@...il.com, arnd@...db.de
Subject: Re: [PATCH v10 00/14] add the latest exfat driver
On Wed, Jan 15, 2020 at 10:47:32AM +0100, Pali Rohár wrote:
> Next steps for future:
>
> * De-duplicate cache code between fat and exfat. Currently fs/exfat
> cache code is heavily copy-paste of fs/fat cache code.
As said before I don't think this should be a merge blocker. I actually
see this more of an experiment as the sharing might make things worse.
But at least it is worth giving it a try.
> * De-duplicate UTF-16 functions. Currently fs/exfat has e.g. helper
> functions for surrogate pairs copy-paste from fs/nls.
If you looked into that can you post a list of suspected duplicates?
>
> * Unify EXFAT_DEFAULT_IOCHARSET and FAT_DEFAULT_IOCHARSET. Or maybe
> unify it with other filesystems too.
For the initial merge I think they should be kept separate, as
referencing other file systems Kconfig variable is confusing.
Investingating if we could a single common one sounds like a good idea,
though.
> * After applying this patch series, remote staging exfat implementation.
I think Greg wants to do that separately. I still hope we can do that
in the same merge window, though.
Powered by blists - more mailing lists