From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (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 42159641; Wed, 8 Nov 2023 00:56:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="Dyrs8TH1" Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D11C10F6; Tue, 7 Nov 2023 16:56:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=cuvgmkWOC2IuAeh5mDaz4oGbyGgrwHqcs+Lrz0SU840=; b=Dyrs8TH13oiU4C0vNJHCAJdpiu YUmALd21mxiaLBiPrw1Qc/6r8s63t86Yf/jG4Ex5d0LxpGrSgh+kUFV1iEljld1mkayPar8i0HXJR DapxwmM/tkU7BlxTORQ8LFgtCsrSgIPw3kouwsjgdIEGRgMavN4UsFO8TL3uQI60smXok37esGuxY lPk3A+NJjrEaDZGRXVyi/HmXCclcaUMd2eu73uy14QnpSMz+vlikVshW05H3YvBVPGXYle+F80pMB 7FDHP4KVtcc61rEane4nMZ1ky9fp4REdfJp4w/Y9HI4EE3UG1web/6acUcKdpUXhPpvqblDSXmKxE Ncx0XePw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1r0Wrs-00ClSt-3D; Wed, 08 Nov 2023 00:56:29 +0000 Date: Wed, 8 Nov 2023 00:56:28 +0000 From: Al Viro To: Wedson Almeida Filho Cc: Matthew Wilcox , Christian Brauner , Kent Overstreet , Greg Kroah-Hartman , linux-fsdevel@vger.kernel.org, rust-for-linux@vger.kernel.org, Wedson Almeida Filho Subject: Re: [RFC PATCH 10/19] rust: fs: introduce `FileSystem::read_folio` Message-ID: <20231108005628.GW1957730@ZenIV> References: <20231018122518.128049-1-wedsonaf@gmail.com> <20231018122518.128049-11-wedsonaf@gmail.com> <20231107222257.GV1957730@ZenIV> Precedence: bulk X-Mailing-List: rust-for-linux@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: Sender: Al Viro On Tue, Nov 07, 2023 at 09:35:44PM -0300, Wedson Almeida Filho wrote: > > While we are at it, lookup is also very much not a per-filesystem operation. > > Take a look at e.g. procfs, for an obvious example... > > The C api offers the greatest freedom: one could write a file system > where each file has its own set of mapping_ops, inode_ops and > file_ops; and while we could choose to replicate this freedom in Rust > but we haven't. Too bad. > Mostly because we don't need it, and we've been repeatedly told (by > Greg KH and others) not to introduce abstractions/bindings for > anything for which there isn't a user. Besides being a longstanding > rule in the kernel, they also say that they can't reasonably decide if > the interfaces are good if they can't see the users. The interfaces are *already* there. If it's going to be a separate set of operations for Rust and for the rest of the filesystems, we have a major problem right there. > The existing Rust users (tarfs and puzzlefs) only need a single > lookup. And a quick grep (git grep \\\.lookup\\\> -- fs/) appears to > show that the vast majority of C filesystems only have a single lookup > as well. So we choose simplicity, knowing well that we may have to > revisit it in the future if the needs change. > > > Wait a minute... what in name of everything unholy is that thing doing tied > > to inodes in the first place? > > For the same reason as above, we don't need it in our current > filesystems. A bunch of C ones (e.g., xfs, ext2, romfs, erofs) only > use the dentry to get the name and later call d_splice_alias(), so we > hide the name extraction and call to d_splice_alias() in the > "trampoline" function. What controls the lifecycle of that stuff from the Rust point of view?