Re: [PATCH V10 00/10] famfs: port into fuse

["Dan Williams" <djbw@kernel.org>]

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 PM John Groves <John@groves.net> wrote:
>> >
>> > There is a FUSE_DAX_FMAP capability that the kernel may advertise or 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 be updated
>> > to NEVER advertise the FUSE_DAX_FMAP capability. All of the famfs-specific
>> > code could be taken out of kernels that never advertise that capability.
>> 
>> I’m 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.
>> 
>
> 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=n does not mean userland "is broken", this would
> 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 is available", then userspace can not be surprised when one option disappears. So to give time for the bpf approach to mature the kernel can do something like "famfs and bpf  mapping support are available". In some future kernel the famfs native option disappears after a deprecation period. 

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 clear that native might be gone someday.