Re: [fuse-devel] [PATCH RESEND V12 3/8] fuse: Definitions and ioctl for passthrough

[Nikolaus Rath <Nikolaus@rath.org>]

On May 16 2023, Miklos Szeredi via fuse-devel <fuse-devel@lists.sourceforge.net> wrote:
> On Mon, 15 May 2023 at 23:45, Paul Lawrence <paullawrence@google.com> wrote:
>>
>> On Mon, May 15, 2023 at 2:11 PM Bernd Schubert
>> <bernd.schubert@fastmail.fm> 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 longer
>> > > works, and instead there is a large new API surface that doesn't work 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

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F