On Wed, Sep 13, 2023 at 2:26 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Wed, Sep 13, 2023 at 11:37 AM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > > On Tue, Sep 12, 2023 at 09:54:08PM +0300, Amir Goldstein wrote: > > > Overlayfs stores its files data in backing files on other filesystems. > > > > > > Factor out some common helpers to perform io to backing files, that will > > > later be reused by fuse passthrough code. > > > > > > Suggested-by: Miklos Szeredi <miklos@xxxxxxxxxx> > > > Link: https://lore.kernel.org/r/CAJfpeguhmZbjP3JLqtUy0AdWaHOkAPWeP827BBWwRFEAUgnUcQ@xxxxxxxxxxxxxx > > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > > > --- > > > > > > Miklos, > > > > > > This is the re-factoring that you suggested in the FUSE passthrough > > > patches discussion linked above. > > > > > > This patch is based on the overlayfs prep patch set I just posted [1]. > > > > > > Although overlayfs currently is the only user of these backing file > > > helpers, I am sending this patch to a wider audience in case other > > > filesystem developers want to comment on the abstraction. > > > > > > We could perhaps later considering moving backing_file_open() helper > > > and related code to backing_file.c. > > > > > > In any case, if there are no objections, I plan to queue this work > > > for 6.7 via the overlayfs tree. > > > > > > Thanks, > > > Amir. > > > > > > [1] https://lore.kernel.org/linux-unionfs/20230912173653.3317828-1-amir73il@xxxxxxxxx/ > > > > > > > > > MAINTAINERS | 2 + > > > fs/Kconfig | 4 + > > > fs/Makefile | 1 + > > > fs/backing_file.c | 160 +++++++++++++++++++++++++++++++++++ > > > fs/overlayfs/Kconfig | 1 + > > > fs/overlayfs/file.c | 137 ++---------------------------- > > > fs/overlayfs/overlayfs.h | 2 - > > > fs/overlayfs/super.c | 11 +-- > > > include/linux/backing_file.h | 22 +++++ > > > 9 files changed, 199 insertions(+), 141 deletions(-) > > > create mode 100644 fs/backing_file.c > > > create mode 100644 include/linux/backing_file.h > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 90f13281d297..4e1d21773e0e 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -16092,7 +16092,9 @@ L: linux-unionfs@xxxxxxxxxxxxxxx > > > S: Supported > > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git > > > F: Documentation/filesystems/overlayfs.rst > > > +F: fs/backing_file.c > > > F: fs/overlayfs/ > > > +F: include/linux/backing_file.h > > > > I'd like to do this slightly differently, please. All vfs infra goes > > through vfs trees > > OK. it will take a bit more git collaboration for a new > infra that is not used by any fs yet, but it's fine by me. > > > but for new infra like this where someone steps up to > > be a maintainer we add a new section (like bpf or networking does): > > > > VFS [BACKING FILE] > > M: Miklos Szeredi <miklos@xxxxxxxxxx> > > M: Amir Goldstein <amir73il@xxxxxxxxx> > > F: fs/backing_file.c > > F: include/linux/backing_file.h > > L: linux-fsdevel@xxxxxxxxxxxxxxx > > S: Maintained > > That sounds good. But if you want to follow the ways of BFP and NETWORKING, we first need to agree on the prefix, because there is no ^VFS entry at the moment there is: FILESYSTEMS (VFS and infrastructure) So do you intend to change that, or should we carry on with the ^FILESYSTEM prefix, such as the entry: FILESYSTEM DIRECT ACCESS (DAX) and add the entry: FILESYSTEM [BACKING FILE] Thanks, Amir.
