On 2023-10-11 11:31:17, Darrick J. Wong wrote: > On Fri, Oct 06, 2023 at 08:49:05PM +0200, Andrey Albershteyn wrote: > > diff --git a/include/linux/iomap.h b/include/linux/iomap.h > > index 96dd0acbba44..3565c449f3c9 100644 > > --- a/include/linux/iomap.h > > +++ b/include/linux/iomap.h > > @@ -262,8 +262,25 @@ int iomap_file_buffered_write_punch_delalloc(struct inode *inode, > > struct iomap *iomap, loff_t pos, loff_t length, ssize_t written, > > int (*punch)(struct inode *inode, loff_t pos, loff_t length)); > > > > -int iomap_read_folio(struct folio *folio, const struct iomap_ops *ops); > > -void iomap_readahead(struct readahead_control *, const struct iomap_ops *ops); > > +struct iomap_readpage_ops { > > + /* > > + * Filesystems wishing to attach private information to a direct io bio > > + * must provide a ->submit_io method that attaches the additional > > + * information to the bio and changes the ->bi_end_io callback to a > > + * custom function. This function should, at a minimum, perform any > > + * relevant post-processing of the bio and end with a call to > > + * iomap_read_end_io. > > + */ > > + void (*submit_io)(const struct iomap_iter *iter, struct bio *bio, > > + loff_t file_offset); > > + struct bio_set *bio_set; > > Needs a comment to mention that iomap will allocate bios from @bio_set > if non-null; or its own internal bioset if null. Sure. > > +}; > > It's odd that this patch adds this ops structure but doesn't actually > start using it until the next patch. I wanted to separate iomap changes with xfs changes so it's easier to go through, but I fine with merging these two. -- - Andrey