From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 B6B3F371D0A; Thu, 16 Apr 2026 20:53:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776372827; cv=none; b=JjmIwYLqRgqB32/Yv0F9skYLctJs6L69P3oyq4S6d2QuZ+230rguSl2g79gwrpA3JT9rw80KJLgPgBNgg9IM1zYNiwCUPAEqMPLqvXFgoOemgJN9+heWnEBUWv8zbLq0EP6ytH1LlhmIsywAR7OEvBIdLyi0NRRi5f1I1vfhZME= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776372827; c=relaxed/simple; bh=WrSs9D3ajaYKuB8EpBEH6JutRpPV1nePztytUV2eiHs=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=TL0/xa1I7EqpZ/Ag2sjgfGHL3nazMGHMS1AYSDoC+Kf2IQoGrTCbWiWWIM3A8xibkqwKAR8GVr0Cd1BoJkflCXDCLif9C+43Ps5u3SQ3jeQ+i046J+jWj/ocRUT2YdP0SKTjeS1PzgaPSEOWRbvPW9VBN2n6IMUlYEifD+ioFDg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iJnU0Bu9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iJnU0Bu9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B6BEC2BCB0; Thu, 16 Apr 2026 20:53:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776372827; bh=WrSs9D3ajaYKuB8EpBEH6JutRpPV1nePztytUV2eiHs=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=iJnU0Bu9Fp2a4IIR6Uvsn5yEJALrEieeyO07X5igdL3nn6qyrINXnKXSa3sj15F62 oA33VKZ2J79rZ5PSVroqNFlwwwfE6HyZ1eQbwxOfexBReNtzIjGYeoLeb8TDckm+35 zwU9rlcRGvlYnzQkYay/xjkeyJMsshTM5etYg3la6zc0dnEmJf0u9xUZa3szmd7sJl x9oQfxlQ53kEEZRdoANKMaFiJEzGS+bGYBNLgST69LOP0X8CRXtLnE9j+GcVaGQOAT xZkii60w11Mht5DOBn4/V+ysXrUMpHKn/3BJCGIvP/Y8oLB3TaEf11Dr3J6SIW85c3 G8frIdEoqrH8g== Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfauth.phl.internal (Postfix) with ESMTP id 879EAF40068; Thu, 16 Apr 2026 16:53:45 -0400 (EDT) Received: from phl-imap-16 ([10.202.2.88]) by phl-compute-02.internal (MEProxy); Thu, 16 Apr 2026 16:53:45 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdegkedtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefoggffhffvvefkjghfufgtgfesthhqredtredtjeenucfhrhhomhepfdffrghnucgh ihhllhhirghmshdfuceoughjsgifsehkvghrnhgvlhdrohhrgheqnecuggftrfgrthhtvg hrnhepuedujeffveegleegkeeiteefuefhfeekvedvgfffgeehgfehleejgeejveffgfff necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughjsg ifodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqddujeejvdeftdegheehqdef feefleegtdegjedqughjsgifpeepkhgvrhhnvghlrdhorhhgsehfrghsthhmrghilhdrtg homhdpnhgspghrtghpthhtohepgedupdhmohguvgepshhmthhpohhuthdprhgtphhtthho pehshhhivhgrnhhkghesrghmugdrtghomhdprhgtphhtthhopehjrghmvghsrdhmohhrsh gvsegrrhhmrdgtohhmpdhrtghpthhtohepsggvrhhnugessghssggvrhhnugdrtghomhdp rhgtphhtthhopegsshgthhhusggvrhhtseguughnrdgtohhmpdhrtghpthhtoheprghmih hrjeefihhlsehgmhgrihhlrdgtohhmpdhrtghpthhtohepsggrghgrshguohhtmhgvsehg mhgrihhlrdgtohhmpdhrtghpthhtohepjhhorghnnhgvlhhkohhonhhgsehgmhgrihhlrd gtohhmpdhrtghpthhtoheprggtkhgvrhhlvgihthhnghesghhoohhglhgvrdgtohhmpdhr tghpthhtohepshgvrghnjhgtsehgohhoghhlvgdrtghomh X-ME-Proxy: Feedback-ID: i67ae4b3e:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 5278B2CC0083; Thu, 16 Apr 2026 16:53:45 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Thu, 16 Apr 2026 13:53:27 -0700 From: "Dan Williams" To: "Gregory Price" , "Joanne Koong" Cc: "John Groves" , "Darrick J. Wong" , "Miklos Szeredi" , "Bernd Schubert" , "John Groves" , "Dan J Williams" , "Bernd Schubert" , "Alison Schofield" , "John Groves" , "Jonathan Corbet" , "Shuah Khan" , "Vishal Verma" , "Dave Jiang" , "Matthew Wilcox" , "Jan Kara" , "Alexander Viro" , "David Hildenbrand" , "Christian Brauner" , "Randy Dunlap" , "Jeff Layton" , "Amir Goldstein" , "Jonathan Cameron" , "Stefan Hajnoczi" , "Josef Bacik" , "Bagas Sanjaya" , "Chen Linxuan" , "James Morse" , "Fuad Tabba" , "Sean Christopherson" , "Shivank Garg" , "Ackerley Tng" , "Aravind Ramesh" , "Ajay Joshi" , "venkataravis@micron.com" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "nvdimm@lists.linux.dev" , "linux-cxl@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" Message-Id: <43d36427-4629-4712-a262-391e64006eb5@app.fastmail.com> In-Reply-To: References: <38744253-efa3-41c5-a491-b177a4a4c835@bsbernd.com> <20260414185740.GA604658@frogsfrogsfrogs> Subject: Re: [PATCH V10 00/10] famfs: port into fuse Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 16, 2026, at 1:14 PM, Gregory Price wrote: > On Thu, Apr 16, 2026 at 08:56:46AM -0700, Joanne Koong wrote: >> On Tue, Apr 14, 2026 at 5:10=E2=80=AFPM John Groves = wrote: >> > >> > There is a FUSE_DAX_FMAP capability that the kernel may advertise o= r not >> > at init time; this capability "is" the famfs GET_FMAP AND GET_DAXDEV >> > commands. In the future, if we find a way to use BPF (or some other >> > mechanism) to avoid needing those fuse messages, the kernel could b= e updated >> > to NEVER advertise the FUSE_DAX_FMAP capability. All of the famfs-s= pecific >> > code could be taken out of kernels that never advertise that capabi= lity. >>=20 >> I=E2=80=99m not sure the capability bit can be used like that (though= I am >> hoping it can!). As I understand it, once the kernel advertises a >> capability, it must continue supporting it in future kernels else >> userspace programs that rely on it will break. >>=20 > > FUSE_DAX_FMAP is already conditional on CONFIG_FUSE_DAX, the kernel is > not required to continue advertising FUSE_DAX_FMAP in perpetuity. > > Setting CONFIG_FUSE_DAX=3Dn does not mean userland "is broken", this w= ould > only be the case if FUSE_DAX_FMAP was advertised but not actually > supported. > > If DAX were removed from the kernel (unlikely, but stick with me) this > would be equivalent to permanently changing CONFIG_FUSE_DAX to always > off, and there would be no squabbles over whether that particular > change broke userland (there would be much strife over removing dax). > > While not a deprecation method, this is what capability bits are > designed for. Same as cpuid capability bits - just because the bit is > there doesn't mean a processor is required to support it in perpetuity. > > They're only required to support it if the bit is turned on. > Right, if the protocol on day one is "user space must ask which method i= s available", then userspace can not be surprised when one option disapp= ears. So to give time for the bpf approach to mature the kernel can do s= omething like "famfs and bpf mapping support are available". In some fu= ture kernel the famfs native option disappears after a deprecation perio= d.=20 When folks ask 10 years from now why this ever supported optionality the= explanation is "oh because famfs enjoyed first mover advantage to prove= out fs semantics layered on dax devices", or "turns out there are some = cases where bpf is not fast enough but it still stops the proliferation = of more in kernel mapping implementations". Something like FUSE_DAX_FMAP is always available but the backend to that= is optionally native vs bpf. ...or some other arrangement to make it cl= ear that native might be gone someday.