On Mon, Aug 09, 2021 at 08:12:25AM +0200, Christoph Hellwig wrote: > The iomap_iter struct provides a convenient way to package up and > maintain all the arguments to the various mapping and operation > functions. It is operated on using the iomap_iter() function that > is called in loop until the whole range has been processed. Compared > to the existing iomap_apply() function this avoid an indirect call > for each iteration. > > For now iomap_iter() calls back into the existing ->iomap_begin and > ->iomap_end methods, but in the future this could be further optimized > to avoid indirect calls entirely. > > Based on an earlier patch from Matthew Wilcox <willy@xxxxxxxxxxxxx>. > > Signed-off-by: Christoph Hellwig <hch@xxxxxx> > --- > fs/iomap/Makefile | 1 + > fs/iomap/core.c | 79 +++++++++++++++++++++++++++++++++++++++++++ > fs/iomap/trace.h | 37 +++++++++++++++++++- > include/linux/iomap.h | 56 ++++++++++++++++++++++++++++++ > 4 files changed, 172 insertions(+), 1 deletion(-) > create mode 100644 fs/iomap/core.c > > diff --git a/fs/iomap/Makefile b/fs/iomap/Makefile > index eef2722d93a183..6b56b10ded347a 100644 > --- a/fs/iomap/Makefile > +++ b/fs/iomap/Makefile > @@ -10,6 +10,7 @@ obj-$(CONFIG_FS_IOMAP) += iomap.o > > iomap-y += trace.o \ > apply.o \ > + core.o \ This creates a discontinuity in the iomap git history. Can you add these new functions to iomap/apply.c, then when the old apply code is removed later in the series rename the file to core.c? At least that way 'git log --follow fs/iomap/core.c' will walk back into the current history of fs/iomap/apply.c and the older pre-disaggregation fs/iomap.c without having to take the tree back in time to find those files... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
