"Darrick J. Wong" <djwong@xxxxxxxxxx> writes: > On Mon, Jun 05, 2023 at 04:25:01PM +0530, Ritesh Harjani (IBM) wrote: >> This patch renames the iomap_page_create/release() functions to >> iomap_iop_alloc/free() calls. Later patches adds more functions for >> handling iop structure with iomap_iop_** naming conventions. >> Hence iomap_iop_alloc/free() makes more sense to be consistent with all >> APIs. >> >> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@xxxxxxxxx> >> --- >> fs/iomap/buffered-io.c | 21 +++++++++++---------- >> 1 file changed, 11 insertions(+), 10 deletions(-) >> >> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c >> index 063133ec77f4..4567bdd4fff9 100644 >> --- a/fs/iomap/buffered-io.c >> +++ b/fs/iomap/buffered-io.c >> @@ -43,8 +43,8 @@ static inline struct iomap_page *to_iomap_page(struct folio *folio) >> >> static struct bio_set iomap_ioend_bioset; >> >> -static struct iomap_page * >> -iomap_page_create(struct inode *inode, struct folio *folio, unsigned int flags) >> +static struct iomap_page *iomap_iop_alloc(struct inode *inode, > > Personally I preferred iop_alloc, but as I wasn't around to make to that > point during the v6 review I'll let this slide. iomap_iop_* it is. > > (I invoke maintainer privilege and will rename the structure to > iomap_folio and iop->iof since the objects no longer track /only/ a > single page state.) Darrick, Do you want me to rename iomap_page -> iomap_folio in this patch itself or would you rather prefer the renaming of iomap_page -> iomap_folio and iop -> iof as a separate last patch in the series? > > Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx> > Thanks! -ritesh
