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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54E49C77B7F for ; Tue, 16 May 2023 10:16:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231757AbjEPKQ6 (ORCPT ); Tue, 16 May 2023 06:16:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231297AbjEPKQ4 (ORCPT ); Tue, 16 May 2023 06:16:56 -0400 Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 94550E6A for ; Tue, 16 May 2023 03:16:55 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 03CEB5C00F7; Tue, 16 May 2023 06:16:55 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 16 May 2023 06:16:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rath.org; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1684232214; x=1684318614; bh=qGhMGRAtjxAyCpT0id+n/1+YA9bnkK17mkA CkqhUL14=; b=RophgP+4WwdiSvewq4TqNNQj3wy7J4uDBzgAccpqAMsoDtlOCNy PCrbPy0bkjeaBVDGOwrmGRL0WDblN0rbmUk5lqB6pydNrCgYIjBcir43y9GNJwCk 7QfQJpfwZpMpHABO+F38mrCnxSs1W/NZO1oIuaH8wkSMg1qANJWFifFHimApY7Bg c2F/qZJaOWbcETFF+7T00OYZCFBmDYOKtZ+nLUQJKcgZKj73CwT7M0Hdnxb0nUSd TRLoOrKfhinYxnnOdpCJuUsSzrkz5XfrzoQmeWkwSIKvmkMsvcMHsWz0ZVYdNCsN eMqCv/3H6X+EkTpsiMuhS83RbgnH+Ygu/5Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1684232214; x=1684318614; bh=qGhMGRAtjxAyCpT0id+n/1+YA9bnkK17mkA CkqhUL14=; b=Hxu1NIUZ14WENPhCdzf59xS367C6dtub7jAo7isSqE8XkpE6eFX 0Em3CUmXOyBsZcmMHBC3SvD/B7MbCGHme52LSTMlmZ5HKfR0TSuL3C6gCg6VWtSv q9gOGfC8UPhEOOtEMNbz/+oayJLf1VVXFyfFGSKvYf7iiyYmCNYE2ZqiyqcqusZb Jq28XeLPdu2a/2qW21uQ9kK2hjf/j78zzdkx0Vh3k3VxstMcbkkmycqdsW3o7S9H F+Y2bu6XXPVJNjCgLoyYQ7nZhUDDeEwxC2kRQceyCp245fdGSN499uaa67ZEGKeX asxJkLfR+hNAJzZWaaXiOogj7scT/nYxGzA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeehledgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufhffjgfkfgggtgfgsehtqhdttddtreejnecuhfhrohhmpefpihhk ohhlrghushcutfgrthhhuceopfhikhholhgruhhssehrrghthhdrohhrgheqnecuggftrf grthhtvghrnhepleffjefhgfffiedufeekvdeflefhheejjedugeejuefgleehvdejtdeg kedthfetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eppfhikhholhgruhhssehrrghthhdrohhrgh X-ME-Proxy: Feedback-ID: i53a843ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 16 May 2023 06:16:53 -0400 (EDT) Received: from vostro.rath.org (vostro [192.168.12.4]) by ebox.rath.org (Postfix) with ESMTPS id 84D35DBE; Tue, 16 May 2023 10:16:52 +0000 (UTC) Received: by vostro.rath.org (Postfix, from userid 1000) id 6DBFAD131C; Tue, 16 May 2023 11:16:50 +0100 (BST) From: Nikolaus Rath To: Miklos Szeredi via fuse-devel Cc: Paul Lawrence , Miklos Szeredi , Jens Axboe , Giuseppe Scrivano , Peng Tao , Daniel Borkmann , Jann Horn , Bernd Schubert , Martijn Coenen , Zimuzo Ezeozue , Palmer Dabbelt , Stefano Duo , David Anderson , Akilesh Kailash , "linux-fsdevel@vger.kernel.org" , wuyan , kernel-team Subject: Re: [fuse-devel] [PATCH RESEND V12 3/8] fuse: Definitions and ioctl for passthrough References: <20210125153057.3623715-1-balsini@android.com> <20210125153057.3623715-4-balsini@android.com> <87353xjqoj.fsf@vostro.rath.org> <93b77b5d-a1bc-7bb9-ffea-3876068bd369@fastmail.fm> Mail-Copies-To: never Mail-Followup-To: Miklos Szeredi via fuse-devel , Paul Lawrence , Miklos Szeredi , Jens Axboe , Giuseppe Scrivano , Peng Tao , Daniel Borkmann , Jann Horn , Bernd Schubert , Martijn Coenen , Zimuzo Ezeozue , Palmer Dabbelt , Stefano Duo , David Anderson , Akilesh Kailash , "linux-fsdevel@vger.kernel.org" , wuyan , kernel-team Date: Tue, 16 May 2023 11:16:50 +0100 In-Reply-To: (Miklos Szeredi via fuse-devel's message of "Tue, 16 May 2023 10:43:28 +0200") Message-ID: <87y1loinsd.fsf@vostro.rath.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On May 16 2023, Miklos Szeredi via fuse-devel wrote: > On Mon, 15 May 2023 at 23:45, Paul Lawrence wro= te: >> >> On Mon, May 15, 2023 at 2:11=E2=80=AFPM Bernd Schubert >> wrote: >> > On 5/15/23 22:16, Nikolaus Rath wrote: > >> > > One thing that struck me when we discussed FUSE-BPF at LSF was that = from >> > > a userspace point of view, FUSE-BPF presents an almost completely >> > > different API than traditional FUSE (at least in its current form). >> > > >> > > As long as there is no support for falling back to standard FUSE >> > > callbacks, using FUSE-BPF means that most of the existing API no lon= ger >> > > works, and instead there is a large new API surface that doesn't wor= k in >> > > standard FUSE (the pre-filter and post-filter callbacks for each >> > > operation). >> > > >> > > I think this means that FUSE-BPF file systems won't work with FUSE, = and >> > > FUSE filesystems won't work with FUSE-BPF. >> > >> > Is that so? I think found some incompatibilities in the patches (need = to >> > double check), but doesn't it just do normal fuse operations and then >> > replies with an ioctl to do passthrough? BPF is used for additional >> > filtering, that would have to be done otherwise in userspace. > > I think Nikolaus' concern is that the BPF hooks add a major upgrade to > the API, i.e. it looks very difficult to port a BPF based fs to > non-BPF based fuse. The new API should at least come with sufficient > warnings about portability issues. > > I don't think the other direction has problems. The fuse API/ABI must > remain backward compatible and old filesystems must be able to work > after this feature is added. I wouldn't say I'm concerned, it's more of an observation. To me it seemed like we are combining two very different approaches/interfaces in the same kernel module / userspace library. This doesn't result in a compatibility problem, but it seems to me that we could cleanly split this into two different components (that may share code) with almost no API overlap. But it seems I may have misunderstood some aspects about how the fallback works. Let's wait for the FUSE-BPF patches and then revisit the question :-). Best, -Nikolaus --=20 GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F