Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7624169ybl; Thu, 16 Jan 2020 02:53:45 -0800 (PST) X-Google-Smtp-Source: APXvYqzp08MIWL74EwyOCj8K3XjTkGhZrgk6uaxgYA80d0UfSjMoKxAe+43mUcy77tCcf9h0N94B X-Received: by 2002:aca:1903:: with SMTP id l3mr3636665oii.16.1579172024904; Thu, 16 Jan 2020 02:53:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579172024; cv=none; d=google.com; s=arc-20160816; b=l0ZmfRZ/P5AMT5V1JjPmhu/rvgA7tuFlXrQeIP5w9Hk8jrpQaWIwMRExY1iTj7g5Or 3cQyp/W0+ioHDyRbCgc6kzgnQrZ4pjbCvKiocLue4fOBSCb9td0wOt7/UXTWC07yaHui PtmoOJGdVKkqe1ShAmZEfMRuliD2mhakp/KgJRVepTSKE2eUnMsI9jvNnqphgMylltBB JlzBVLtZq9jhRqrg39FqxEzNTa81oRDYnAK34lmhiFhfQWWU2TR0WhPehzIoF1L0MX1h 4lBjnLzm8lLyCowHimM8HVUQvWf+R+wx16DoeVGDARp1BvVF2snnKS9Fi4lBJjZumE9X p8ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Y9fIW5W0jTPhBao86Bz4H11eVD3pVhRTLTFXIHU9Knw=; b=wIPq+QeTrqThGk0VHPgn40NkLDcWIvdUAC3XFtv9sBdabnpeBwuZQnTdcjxsf40XfL /03VQyr5MVSqsxIRYpPPsmz4GTXaJGj50xWRFbMhngENXuahz+gY6/sy9+g37mnfu5wm OoyTZKuJLHHWal4ftibQggMF18RkfipRnPojrERVq+xGPXnRX89E8zeyv1KwL9HA6t4A z94z1iX0FMhQ5Uq6bMXcZX/qcvU4YnBlc1AdKxKvaawmwTQCx1iy2ulsRFpYPfbyC3A0 FYEqmjSRofjlmlGuGaN6dAPimUkmcoIdnfk3z0c3hzCyyLpEtmw9DAr/I8HbeiBXTbDB 17YQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z1si13145513otm.242.2020.01.16.02.53.33; Thu, 16 Jan 2020 02:53:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729012AbgAPKvX (ORCPT + 99 others); Thu, 16 Jan 2020 05:51:23 -0500 Received: from verein.lst.de ([213.95.11.211]:55329 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726187AbgAPKvM (ORCPT ); Thu, 16 Jan 2020 05:51:12 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id 0DE4F68B20; Thu, 16 Jan 2020 11:51:09 +0100 (CET) Date: Thu, 16 Jan 2020 11:51:08 +0100 From: Christoph Hellwig To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Namjae Jeon , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, gregkh@linuxfoundation.org, valdis.kletnieks@vt.edu, hch@lst.de, sj1557.seo@samsung.com, linkinjeon@gmail.com, arnd@arndb.de Subject: Re: [PATCH v10 00/14] add the latest exfat driver Message-ID: <20200116105108.GA16924@lst.de> References: <20200115082447.19520-1-namjae.jeon@samsung.com> <20200115094732.bou23s3bduxpnr4k@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200115094732.bou23s3bduxpnr4k@pali> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.