Re: [PATCH V12 02/12] famfs: Module operations, fs_context, and mount

["David Hildenbrand (Arm)" <david@kernel.org>]

On 8/11/26 11:24, Christian Brauner wrote:
> On Tue, Aug 11, 2026 at 10:59:50AM +0200, Miklos Szeredi wrote:
>> On Thu, 6 Aug 2026 at 06:37, Darrick J. Wong <djwong@kernel.org> wrote:
>>
>>> IOWs, let's fix the remaining wobbles (if any) and just merge this
>>> already.  No more side quests through gigantic refactorings of fusex,
>>> that's too much to ask after you already redesigned and reimplemented
>>> the whole thing already.
>>
>> Without any intention to change the direction, let me just state some facts:
>>
>>  - it was never suggested that famfs depend on the fusex work in any way
>>
>>  - the plan to add famfs mappings to fuse was laid out two and a half
>> years ago in reply to the very first rfc posting and has basically
>> remained unchanged since then:
>>
>> https://lore.kernel.org/all/CAJfpegv8XzFvty_x00UehUQxw9ai8BytvGNXE8SL03zfsTN6ag@mail.gmail.com/
>>
>> I understand how that seemingly simple API addition was overwhelming
>> for John, and I should have been more proactive in helping with the
>> implementation.  That's entirely my fault.
>>
>> On the other hand John could have been more trusting that the plan will work.
>>
>> But that's behind us now, let's move on...
> 
> with fuse, please...

Okay, we're now (again? :) ) in a difficult situation where some people support
standalone famfs, while other people (including Christian) prefer a fuse version.

The history on the fuse approach hasn't exactly been a role model (bpf is where
things really went wrong), so I understand the pushback from John. At the same
time, I also read that the earlier fuse problems might now have been solved and
that there were many misunderstandings.

Reading the arguments from both sides, I think we're missing a common
understanding when it comes to the fuse-based approach of:

(a) Whether a fuse-based approach is feasible.

    Are there any major blockers remaining?

(b) Whether a fuse-based approach is inefficient.

    Are there scenarios remaining where performance or metadata overhead would
    be bad without an easy way to improve the situation?

(c) Whether a fuse-based approach is a bad conceptual fit.

    Will fuse have to carry a lot of famfs special sauce that cannot
    really be used elsewhere / generalized?

(d) Whether a fuse-based approach is too invasive.

    Will fuse extensions to support famfs actually make it harder to maintain or
    slower on some paths?

(e) Whether a fuse-based approach will make famfs harder to extend.

    Is there known follow-up work that will be hard/impossible to model in fuse?

(f) Whether a fuse-based approach will reduce maintenance effort.

    Will maintaining fuse extensions possibly be harder than maintaining
    standalone famfs?

(g) Whether a fuse-based approach would make famfs more complex.

    Will the shift to user space result in a significantly more complicated
    overall solution that must be maintained?

(h) Who would help drive the fuse approach?

    Fuse people seem to be willing to help, but I expect that there must be a
    close cooperation with John to make this fly. I don't expect that John
    himself can easily (or understandably wants to :) ) do the heavy fuse
    lifting.

(i) Who would maintain any famfs fuse extensions and own any bugs?

    famfs will possibly depend on fuse extensions that might initially only be
    used by famfs. Would the fuse maintainers just naturally deal with that?

(j) Whether a fuse-based approach has an end in sight.

    famfs goes back .... quite a long time. It would be nice to close that
    chapter :)

    Is there an end in sight, or could we end up in the same situation in 6m/1y/
    ...

    IOW, is there a way to agree on an MVP that won't require a lot of further
    re-planning and changes to a fuse-based design?


In the past there were plenty of misunderstandings. People can continue figuring
this out on the list, not sure how well that will go :)

I know that John had calls with fuse folks in the past. Maybe it makes sense for
all parties (including all relevant maintainers) to have a focused meeting where
they can go through the points raised above and try to get a common understanding?

Sure, opinions will still differ, but I'd hope that we can at least try to
minimize misunderstandings.

I don't have a strong opinion on either approach, I think the most important
part is to find a way forward that will get famfs over the finishing line.

-- 
Cheers,

David