Message ID | 2265065.1703250126@warthog.procyon.org.uk |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-9738-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2483:b0:fb:cd0c:d3e with SMTP id q3csp1043287dyi; Fri, 22 Dec 2023 05:03:14 -0800 (PST) X-Google-Smtp-Source: AGHT+IF39wZTe7HzuXbH1GOWrEPnrhJa/uF8VZG4QOYf0moRDVYv3A1lL3FsGIfwVJOp+Slt8RHW X-Received: by 2002:a05:6a20:2446:b0:195:1462:187b with SMTP id t6-20020a056a20244600b001951462187bmr928915pzc.15.1703250193987; Fri, 22 Dec 2023 05:03:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703250193; cv=none; d=google.com; s=arc-20160816; b=XYmFf2kGlDhItw8mfMGkKXbSfJYav2IF3jMwDpybIrzqGb1qIExex/oiPCKNTxKXUA cOd6m0WXeVTSUVJShyIWQp3vFaE3dE78xV7drjP7F6zybUi2v2TJ/hIQ99B7rhS8bYFq HvelUB2DLrjJ9RvEdHxmGbUYaCYS7FrsL1VmM1nVqdGzky+bx9Ffd9/ZlXiQKVip+6vR nmzjESgqEcXvw2FT9kp/cprQjIV8qw42JcRIX92m3/MlQaxzN6XzW/PN4yHgTl0z2vE0 gM93eZipUqZ+F1+h0Z/11XAFdjRM1Z+FH02utIEDzHgKE9DrWPFMLfVtspUof89NK38G KQLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:content-transfer-encoding:content-id:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:subject:cc:to :references:in-reply-to:from:organization:dkim-signature; bh=2kygMq0mAMv991cW3YZ7Hd3ppnOgYBjhmi7vw/LesYI=; fh=Mwp5jdHBE8+WZ+QhDx0Zvk2DkJu8z45fEMGGbscGfGA=; b=JOIK1hJXeII7e4VU7TIGMqQfBLnGr0OScLm72xjzdaNNePbdhs/B0v2vzyObrA7s7I 9D8jP4MGMTu2Z4IOzUGk22MuFagFeHQtXojsBpCqPpu2uisDgxhB2wAnIELDGoTXb7Jd dOjXSHU9Yj7m2FnzKTOQuBuotzRDW5BF7ajdE+hAAMS/pxsCP99x4jmQAfo6dXl/5FnP ARV3yLwOBUfTjEfOGc+/y8S/RzEbWIYGtC+9iSCpHe4sy1/jYf1E+O5lhmVB2IK0VEzo vFb4hk6TkglOFfJZ1Jw6E/rg9zKiHmYvLm9/1NEeddGAzt0MImkXFGpJwsgRpYAnYPA6 Ro3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dZ1e9KhT; spf=pass (google.com: domain of linux-kernel+bounces-9738-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-9738-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id o27-20020a63921b000000b005c6650f66b5si3243538pgd.267.2023.12.22.05.03.13 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Dec 2023 05:03:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-9738-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dZ1e9KhT; spf=pass (google.com: domain of linux-kernel+bounces-9738-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-9738-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 79D19B2243F for <ouuuleilei@gmail.com>; Fri, 22 Dec 2023 13:03:12 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DB17E21101; Fri, 22 Dec 2023 13:02:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="dZ1e9KhT" X-Original-To: linux-kernel@vger.kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D8A5D199CE for <linux-kernel@vger.kernel.org>; Fri, 22 Dec 2023 13:02:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1703250136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2kygMq0mAMv991cW3YZ7Hd3ppnOgYBjhmi7vw/LesYI=; b=dZ1e9KhTvX+xKy8AnVwJ6n0jAVcEDevkFHa/uRAfZnWhmcJ8q7/tu8JHPUfIE8b1AIUd6n Ydo6uigR79tiBBozV1myyNWlw3vhgeiy4KnPkgd/daBX60dde+m1uCmH15Me49CfNUQ9PY +G1xU0xT2377d/fUt54zr6dWSvrxpwo= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-15--QeBZETQMO6dAe6PTzC6cQ-1; Fri, 22 Dec 2023 08:02:12 -0500 X-MC-Unique: -QeBZETQMO6dAe6PTzC6cQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5329D386914F; Fri, 22 Dec 2023 13:02:11 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.39.195.169]) by smtp.corp.redhat.com (Postfix) with ESMTP id 82A9251E3; Fri, 22 Dec 2023 13:02:07 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells <dhowells@redhat.com> In-Reply-To: <20231221132400.1601991-5-dhowells@redhat.com> References: <20231221132400.1601991-5-dhowells@redhat.com> <20231221132400.1601991-1-dhowells@redhat.com> To: Jeff Layton <jlayton@kernel.org> Cc: dhowells@redhat.com, Gao Xiang <xiang@kernel.org>, Chao Yu <chao@kernel.org>, Yue Hu <huyue2@coolpad.com>, Jeffle Xu <jefflexu@linux.alibaba.com>, Steve French <smfrench@gmail.com>, Matthew Wilcox <willy@infradead.org>, Marc Dionne <marc.dionne@auristor.com>, Paulo Alcantara <pc@manguebit.com>, Shyam Prasad N <sprasad@microsoft.com>, Tom Talpey <tom@talpey.com>, Dominique Martinet <asmadeus@codewreck.org>, Eric Van Hensbergen <ericvh@kernel.org>, Ilya Dryomov <idryomov@gmail.com>, Christian Brauner <christian@brauner.io>, linux-cachefs@redhat.com, linux-afs@lists.infradead.org, linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org, ceph-devel@vger.kernel.org, v9fs@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-erofs@lists.ozlabs.org Subject: [PATCH] Fix EROFS Kconfig Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2265064.1703250126.1@warthog.procyon.org.uk> Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Dec 2023 13:02:06 +0000 Message-ID: <2265065.1703250126@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785987275790203704 X-GMAIL-MSGID: 1785987275790203704 |
Series |
Fix EROFS Kconfig
|
|
Commit Message
David Howells
Dec. 22, 2023, 1:02 p.m. UTC
This needs an additional change (see attached).
Comments
Hi, On 12/22/23 9:02 PM, David Howells wrote: > This needs an additional change (see attached). > > diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig > index 1d318f85232d..1949763e66aa 100644 > --- a/fs/erofs/Kconfig > +++ b/fs/erofs/Kconfig > @@ -114,7 +114,8 @@ config EROFS_FS_ZIP_DEFLATE > > config EROFS_FS_ONDEMAND > bool "EROFS fscache-based on-demand read support" > - depends on CACHEFILES_ONDEMAND && (EROFS_FS=m && FSCACHE || EROFS_FS=y && FSCACHE=y) > + depends on CACHEFILES_ONDEMAND && FSCACHE && \ > + (EROFS_FS=m && NETFS_SUPPORT || EROFS_FS=y && NETFS_SUPPORT=y) > default n > help > This permits EROFS to use fscache-backed data blobs with on-demand > Thanks for the special reminder. I noticed that it has been included in this commit[*] in the dev tree. [*] https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=netfs-lib&id=7472173cc3baf4a0bd8c803e56c37efdb8388f1c Besides I noticed an issue when trying to configure EROFS_FS_ONDEMAND. The above kconfig indicates that EROFS_FS_ONDEMAND depends on NETFS_SUPPORT, while NETFS_SUPPORT has no prompt in menuconfig and can only be selected by, e.g. fs/ceph/Kconfig: config CEPH_FS select NETFS_SUPPORT IOW EROFS_FS_ONDEMAND will not be prompted and has no way being configured if NETFS_SUPPORT itself is not selected by any other filesystem. I tried to fix this in following way: diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig index 1949763e66aa..5b7b71e537f1 100644 --- a/fs/erofs/Kconfig +++ b/fs/erofs/Kconfig @@ -5,6 +5,7 @@ config EROFS_FS depends on BLOCK select FS_IOMAP select LIBCRC32C + select NETFS_SUPPORT if EROFS_FS_ONDEMAND help EROFS (Enhanced Read-Only File System) is a lightweight read-only file system with modern designs (e.g. no buffer heads, inline @@ -114,8 +115,10 @@ config EROFS_FS_ZIP_DEFLATE config EROFS_FS_ONDEMAND bool "EROFS fscache-based on-demand read support" - depends on CACHEFILES_ONDEMAND && FSCACHE && \ - (EROFS_FS=m && NETFS_SUPPORT || EROFS_FS=y && NETFS_SUPPORT=y) + depends on EROFS_FS + select FSCACHE default n help This permits EROFS to use fscache-backed data blobs with on-demand But still the dependency for CACHEFILES_ONDEMAND and CACHEFILES can not be resolved. Though CACHEFILES is not a must during the linking stage as EROFS only calls fscache APIs directly, CACHEFILES is indeed needed to ensure that the EROFS on-demand functionality works at runtime. If we let EROFS_FS_ONDEMAND select CACHEFILES_ONDEMAND, then only CACHEFILES_ONDEMAND will be selected while CACHEFILES can be still N. Maybe EROFS_FS_ONDEMAND needs to selct both CACHEFILES_ONDEMAND and CACHEFILES? Besides if we make EROFS_FS_ONDEMAND depends on CACHEFILES_ONDEMAND, then there will be a recursive dependency loop, as fs/netfs/Kconfig:3:error: recursive dependency detected! fs/netfs/Kconfig:3: symbol NETFS_SUPPORT is selected by EROFS_FS_ONDEMAND fs/erofs/Kconfig:116: symbol EROFS_FS_ONDEMAND depends on CACHEFILES_ONDEMAND fs/cachefiles/Kconfig:30: symbol CACHEFILES_ONDEMAND depends on CACHEFILES fs/cachefiles/Kconfig:3: symbol CACHEFILES depends on NETFS_SUPPORT Hi Xiang, any better idea?
Hi David and Jingbo, On 2023/12/23 11:55, Jingbo Xu wrote: > Hi, > > On 12/22/23 9:02 PM, David Howells wrote: >> This needs an additional change (see attached). >> >> diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig >> index 1d318f85232d..1949763e66aa 100644 >> --- a/fs/erofs/Kconfig >> +++ b/fs/erofs/Kconfig >> @@ -114,7 +114,8 @@ config EROFS_FS_ZIP_DEFLATE >> >> config EROFS_FS_ONDEMAND >> bool "EROFS fscache-based on-demand read support" >> - depends on CACHEFILES_ONDEMAND && (EROFS_FS=m && FSCACHE || EROFS_FS=y && FSCACHE=y) >> + depends on CACHEFILES_ONDEMAND && FSCACHE && \ >> + (EROFS_FS=m && NETFS_SUPPORT || EROFS_FS=y && NETFS_SUPPORT=y) >> default n >> help >> This permits EROFS to use fscache-backed data blobs with on-demand >> > > Thanks for the special reminder. I noticed that it has been included in > this commit[*] in the dev tree. > > [*] > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=netfs-lib&id=7472173cc3baf4a0bd8c803e56c37efdb8388f1c > > > Besides I noticed an issue when trying to configure EROFS_FS_ONDEMAND. > The above kconfig indicates that EROFS_FS_ONDEMAND depends on > NETFS_SUPPORT, while NETFS_SUPPORT has no prompt in menuconfig and can > only be selected by, e.g. fs/ceph/Kconfig: > > config CEPH_FS > select NETFS_SUPPORT > > IOW EROFS_FS_ONDEMAND will not be prompted and has no way being > configured if NETFS_SUPPORT itself is not selected by any other filesystem. > > > I tried to fix this in following way: > > diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig > index 1949763e66aa..5b7b71e537f1 100644 > --- a/fs/erofs/Kconfig > +++ b/fs/erofs/Kconfig > @@ -5,6 +5,7 @@ config EROFS_FS > depends on BLOCK > select FS_IOMAP > select LIBCRC32C > + select NETFS_SUPPORT if EROFS_FS_ONDEMAND > help > EROFS (Enhanced Read-Only File System) is a lightweight read-only > file system with modern designs (e.g. no buffer heads, inline > @@ -114,8 +115,10 @@ config EROFS_FS_ZIP_DEFLATE > > config EROFS_FS_ONDEMAND > bool "EROFS fscache-based on-demand read support" > - depends on CACHEFILES_ONDEMAND && FSCACHE && \ > - (EROFS_FS=m && NETFS_SUPPORT || EROFS_FS=y && > NETFS_SUPPORT=y) > + depends on EROFS_FS > + select FSCACHE > default n > help > This permits EROFS to use fscache-backed data blobs with on-demand > > > But still the dependency for CACHEFILES_ONDEMAND and CACHEFILES can not > be resolved. Though CACHEFILES is not a must during the linking stage > as EROFS only calls fscache APIs directly, CACHEFILES is indeed needed > to ensure that the EROFS on-demand functionality works at runtime. > > If we let EROFS_FS_ONDEMAND select CACHEFILES_ONDEMAND, then only > CACHEFILES_ONDEMAND will be selected while CACHEFILES can be still N. > Maybe EROFS_FS_ONDEMAND needs to selct both CACHEFILES_ONDEMAND and > CACHEFILES? I think the main point here is that we don't have an explicit menuconfig item for either netfs or fscache directly. In principle, EROFS ondemand feature only needs fscache "volume and cookie" management framework as well as cachefiles since they're all needed to manage EROFS cached blobs, but I'm fine if that needs NETFS_SUPPORT is also enabled. If netfs doesn't have a plan for a new explicit menuconfig item for users to use, I think we have to enable as below: diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig index 1d318f85232d..fffd3919343e 100644 --- a/fs/erofs/Kconfig +++ b/fs/erofs/Kconfig @@ -114,8 +114,11 @@ config EROFS_FS_ZIP_DEFLATE config EROFS_FS_ONDEMAND bool "EROFS fscache-based on-demand read support" - depends on CACHEFILES_ONDEMAND && (EROFS_FS=m && FSCACHE || EROFS_FS=y && FSCACHE=y) - default n + depends on EROFS_FS + select NETFS_SUPPORT + select FSCACHE + select CACHEFILES + select CACHEFILES_ONDEMAND help This permits EROFS to use fscache-backed data blobs with on-demand read support. -- 2.39.3 But cachefiles won't be complied as modules anymore. Does it sounds good? Thanks, Gao Xiang
diff --git a/fs/erofs/Kconfig b/fs/erofs/Kconfig index 1d318f85232d..1949763e66aa 100644 --- a/fs/erofs/Kconfig +++ b/fs/erofs/Kconfig @@ -114,7 +114,8 @@ config EROFS_FS_ZIP_DEFLATE config EROFS_FS_ONDEMAND bool "EROFS fscache-based on-demand read support" - depends on CACHEFILES_ONDEMAND && (EROFS_FS=m && FSCACHE || EROFS_FS=y && FSCACHE=y) + depends on CACHEFILES_ONDEMAND && FSCACHE && \ + (EROFS_FS=m && NETFS_SUPPORT || EROFS_FS=y && NETFS_SUPPORT=y) default n help This permits EROFS to use fscache-backed data blobs with on-demand