On Fri, Jul 16, 2021 at 04:21:25AM +0100, Matthew Wilcox wrote: > On Thu, Jul 15, 2021 at 02:21:05PM -0700, Darrick J. Wong wrote: > > On Thu, Jul 15, 2021 at 04:36:23AM +0100, Matthew Wilcox (Oracle) wrote: > > > All but one caller already has the iomap_page, and we can avoid getting > > > it again. > > > > > > Signed-off-by: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx> > > > > Took me a while to distinguish iomap_iop_set_range_uptodate and > > iomap_set_range_uptodate, but yes, this looks pretty simple. > > Not my favourite naming, but it's a preexisting condition ;-) > > Honestly I'd like to rename iomap to blkmap or something. > And iomap_page is now hilariously badly named. But that's kind > of tangential to everything else here. I guess we only use 'blkmap' in a few places in the kernel, and nobody's going to confuse us with UFS. Hmm, what kind of new name? struct iomap_buffer_head *ibh; /* NO */ struct iomap_folio_state *ifs; struct iomap_state *is; /* shorter, but what is 'state'? */ struct iomap_blkmap *ibm; /* lolz */ I think iomap_blkmap sounds fine, since we're probably going to end up exporting it (and therefore need a clear namespace) as soon as one of the filesystems that uses page->private to stash per-page info wants to use iomap for buffered io. --D
