On Fri, Apr 17, 2026 at 1:04 AM Christoph Hellwig <[email protected]> wrote: > > This is the first mail without annoying and pointless full quotes, > so chiming in here. Sorry if I missed something important in all the > noise. > > On Tue, Apr 14, 2026 at 03:19:36PM +0200, Miklos Szeredi wrote: > > On Fri, 10 Apr 2026 at 21:44, Joanne Koong <[email protected]> wrote: > > > > > Overall, my intention with bringing this up is just to make sure we're > > > at least aware of this alternative before anything is merged and > > > permanent. If Miklos and you think we should land this series, then > > > I'm on board with that. > > > > TBH, I'd prefer not to add the famfs specific mapping interface if not > > absolutely necessary. > > Yes, fuse needing support for a specific file systems sounds like a > design mistake. > > >This was the main sticking point originally, > > but there seemed to be no better alternative. > > > > However with the bpf approach this would be gone, which is great. > > So what is this bpf magic actually trying to solve?
It is trying to avoid having famfs-specific implementation details hardcoded permanently into fuse's uapi and kernel code. I really like your suggestion of adding generic stride/offset multi-device support to fs/iomap. That is a much better solution than bpf. Thanks, Joanne >
