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. Thanks, Miklos
