On May 16 2023, Miklos Szeredi via fuse-devel <fuse-devel@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 15 May 2023 at 23:45, Paul Lawrence <paullawrence@xxxxxxxxxx> wrote: >> >> On Mon, May 15, 2023 at 2:11 PM Bernd Schubert >> <bernd.schubert@xxxxxxxxxxx> 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
