From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (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 89363481FB9; Thu, 2 Jul 2026 14:07:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783001233; cv=none; b=PzkBtdKnWs41VyDAX2BjGa399bxWuoV0pnmzRAzI3hAbC4uJpzS/N178giBdqK1pXETq4AKdPembg4XOhRNFsez5lfB0oKpjVqQOstTUGpa34N0LEgiiHAbDYvlJpfOfTHFCETcm6fnaiIOxJqH05Ni1ARzy0AJCOYM6a43akfs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783001233; c=relaxed/simple; bh=F/tM2eAzg331w2LaSdd/nlcr+scQCGc/VlLA8+T5PuU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=t4aYpOKKs2cWrMz3wfzaGjLWNJsNGDcH/Pmm7xbeYS8bE6DBGZkocFL4swVxTvpDVjBCm1EYhwDTXNUVhigkP4/iG5LKxk+oWUHBZ7s8L7QXEnV/7Us+0oaxax/fbkBEoFoTG6vVnAKoZSZU3JvsxW0iWmVmqy2z5TIDwHNeiMw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de Received: by verein.lst.de (Postfix, from userid 2407) id 90D9968BEB; Thu, 2 Jul 2026 16:07:05 +0200 (CEST) Date: Thu, 2 Jul 2026 16:07:05 +0200 From: Christoph Hellwig To: Joanne Koong Cc: brauner@kernel.org, hch@lst.de, djwong@kernel.org, willy@infradead.org, hsiangkao@linux.alibaba.com, linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, Jens Axboe , Chris Mason , David Sterba , Alexander Viro , Jan Kara , Dan Williams , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , Namjae Jeon , Sungjong Seo , Yuezhang Mo , Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , "Ritesh Harjani (IBM)" , Zhang Yi , Jaegeuk Kim , Miklos Szeredi , Andreas Gruenbacher , Mikulas Patocka , Hyunchul Lee , Konstantin Komarov , Carlos Maiolino , Damien Le Moal , Naohiro Aota , Johannes Thumshirn , "open list:BLOCK LAYER" , open list , "open list:BTRFS FILE SYSTEM" , "open list:FILESYSTEM DIRECT ACCESS (DAX)" , "open list:EROFS FILE SYSTEM" , "open list:EXT2 FILE SYSTEM" , "open list:F2FS FILE SYSTEM" , "open list:FUSE FILESYSTEM [CORE]" , "open list:GFS2 FILE SYSTEM" , "open list:NTFS3 FILESYSTEM" Subject: Re: [PATCH v2 17/18] iomap: pass iomap_next_fn directly instead of struct iomap_ops Message-ID: <20260702140705.GE21339@lst.de> References: <20260701000949.1666714-1-joannelkoong@gmail.com> <20260701000949.1666714-18-joannelkoong@gmail.com> Precedence: bulk X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260701000949.1666714-18-joannelkoong@gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Looks good: Reviewed-by: Christoph Hellwig In terms of merge logistics, I wonder if we should delay this and the previous patch to the next merge window so that we can minimize the cross-subsystem merge pain with more file system iomap conversion. If none of them actually happen until rc6 or so, orif the merges aren't painful we could still pick them up late in the merge window.