From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) (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 C4FCE1CF94; Wed, 3 Jan 2024 19:54:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ftp.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="C41nZn4h" 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=SP0nbnT3AvmqkH3t2fYH0Mm3KoSoMBeL9IG/d+j/s5o=; b=C41nZn4h4ycXV0ug3wUFS8f1lp eyGdP3MdWkUv+7im/gYX+nOas2NQCmCRcmMk57LyHtR9/6AkuDBmpTxmMEzBmPonKpm5e63bU9qup a3JqPf8kcM9JfiEoAt8PeMM4/R0p77ZdwkVBEo07l5KcUlFLfNIbDuUJ3PaLV/TJxOJn3fQUt12vY uSXEzKWS0SAeWfT/h0InIMfing5epQ6vwMj2MHGdabEr9kZB+HuvyMffRBhD6Qiei7K/aDbyxWQiI /GFg9YAGwqpf0ubEA+kcoBKg9vAMyV3Kv61WoUq+bSYrqi/if0RM67kI3VqcOVktFbTsY8wuleCm1 gOtXNcAQ==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1rL7JO-000gHq-1E; Wed, 03 Jan 2024 19:53:58 +0000 Date: Wed, 3 Jan 2024 19:53:58 +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 00/19] Rust abstractions for VFS Message-ID: <20240103195358.GK1674809@ZenIV> References: <20231018122518.128049-1-wedsonaf@gmail.com> 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 Wed, Jan 03, 2024 at 04:04:26PM -0300, Wedson Almeida Filho wrote: > > Either stick to the object orientation we've already defined (ie > > separate aops, iops, fops, ... with substantially similar arguments) > > or propose changes to the ones we have in C. Dealing only with toy > > filesystems is leading you to bad architecture. > > I'm trying to understand the argument here. Are saying that Rust > cannot have different APIs with the same performance characteristics > as C's, unless we also fix the C apis? Different expressive power, not performance characteristics. It's *NOT* about C vs Rust; we have an existing system of objects and properties of such. Independent from the language being used to work with them. If we have to keep a separate system for your language, feel free to fork the kernel and do whatever you want with it. Just don't expect anybody else to play with your toy. In case it's not entirely obvious - your arguments about not needing something or other for the instances you have tried to work with so far do not hold water. At all. The only acceptable way to use Rust in that space is to treat the existing set of objects and operations as externally given; we *can* change those, with good enough reasons, but "the instances in Rust-using filesystems don't need this and that" doesn't cut it. Changes do happen in that area. Often enough. And the cost of figuring out whether they break things shouldn't be doubled because Rust folks want a universe of their own - the benefits of Rust are not worth that kind of bother.