On Wed, Jan 08, 2025 at 11:02:31PM -0800, Christoph Hellwig wrote: > On Fri, Dec 13, 2024 at 09:36:06AM -0500, Brian Foster wrote: > > In preparation to support more granular iomap iter advancing, factor > > the pos/len values as parameters to length calculation. > > > > Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx> > > --- > > include/linux/iomap.h | 10 ++++++++-- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/include/linux/iomap.h b/include/linux/iomap.h > > index 5675af6b740c..cbacccb3fb14 100644 > > --- a/include/linux/iomap.h > > +++ b/include/linux/iomap.h > > @@ -236,13 +236,19 @@ int iomap_iter(struct iomap_iter *iter, const struct iomap_ops *ops); > > * > > * Returns the length that the operation applies to for the current iteration. > > */ > > -static inline u64 iomap_length(const struct iomap_iter *iter) > > +static inline u64 __iomap_length(const struct iomap_iter *iter, loff_t pos, > > + u64 len) > > __iomap_length is not a a very good name for this, maybe something like > iomap_cap_length? Also please move the kerneldoc comment for > iomap_length down to be next to it. > Ok, seems reasonable, though I think I'd prefer something like iomap_length_trim().. Brian
