From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B92B1C3A5A7 for ; Mon, 2 Sep 2019 14:20:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9A23422CF7 for ; Mon, 2 Sep 2019 14:20:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731485AbfIBOUV (ORCPT ); Mon, 2 Sep 2019 10:20:21 -0400 Received: from mx2.suse.de ([195.135.220.15]:55342 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731097AbfIBOUV (ORCPT ); Mon, 2 Sep 2019 10:20:21 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id AB78EAD4E; Mon, 2 Sep 2019 14:20:18 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 080BADA796; Mon, 2 Sep 2019 16:20:37 +0200 (CEST) Date: Mon, 2 Sep 2019 16:20:37 +0200 From: David Sterba To: Chao Yu Cc: dsterba@suse.cz, Christoph Hellwig , Gao Xiang , linux-fsdevel@vger.kernel.org, devel@driverdev.osuosl.org, Alexander Viro , LKML , Greg Kroah-Hartman , Andrew Morton , Stephen Rothwell , Theodore Ts'o , Pavel Machek , Amir Goldstein , "Darrick J . Wong" , Dave Chinner , Jaegeuk Kim , Jan Kara , Richard Weinberger , Linus Torvalds , linux-erofs@lists.ozlabs.org, Chao Yu , Miao Xie , Li Guifu , Fang Wei Subject: Re: [PATCH v8 11/24] erofs: introduce xattr & posixacl support Message-ID: <20190902142037.GW2752@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Chao Yu , Christoph Hellwig , Gao Xiang , linux-fsdevel@vger.kernel.org, devel@driverdev.osuosl.org, Alexander Viro , LKML , Greg Kroah-Hartman , Andrew Morton , Stephen Rothwell , Theodore Ts'o , Pavel Machek , Amir Goldstein , "Darrick J . Wong" , Dave Chinner , Jaegeuk Kim , Jan Kara , Richard Weinberger , Linus Torvalds , linux-erofs@lists.ozlabs.org, Chao Yu , Miao Xie , Li Guifu , Fang Wei References: <20190815044155.88483-1-gaoxiang25@huawei.com> <20190815044155.88483-12-gaoxiang25@huawei.com> <20190902125711.GA23462@infradead.org> <20190902130644.GT2752@suse.cz> <813e1b65-e6ba-631c-6506-f356738c477f@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <813e1b65-e6ba-631c-6506-f356738c477f@kernel.org> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Sep 02, 2019 at 09:51:59PM +0800, Chao Yu wrote: > On 2019-9-2 21:06, David Sterba wrote: > > On Mon, Sep 02, 2019 at 05:57:11AM -0700, Christoph Hellwig wrote: > >>> +config EROFS_FS_XATTR > >>> + bool "EROFS extended attributes" > >>> + depends on EROFS_FS > >>> + default y > >>> + help > >>> + Extended attributes are name:value pairs associated with inodes by > >>> + the kernel or by users (see the attr(5) manual page, or visit > >>> + for details). > >>> + > >>> + If unsure, say N. > >>> + > >>> +config EROFS_FS_POSIX_ACL > >>> + bool "EROFS Access Control Lists" > >>> + depends on EROFS_FS_XATTR > >>> + select FS_POSIX_ACL > >>> + default y > >> > >> Is there any good reason to make these optional these days? > > > > I objected against adding so many config options, not to say for the > > standard features. The various cache strategies or other implementation > > details have been removed but I agree that making xattr/acl configurable > > is not necessary as well. > > I can see similar *_ACL option in btrfs/ext4/xfs, should we remove them as well > due to the same reason? Oh right, I think the reasons are historical and that we can remove the options nowadays. From the compatibility POV this should be safe, with ACLs compiled out, no tool would use them, and no harm done when the code is present but not used. There were some efforts by embedded guys to make parts of kernel more configurable to allow removing subsystems to reduce the final image size. In this case I don't think it would make any noticeable difference, eg. the size of fs/btrfs/acl.o on release config is 1.6KiB, while the whole module is over 1.3MiB.