On Wed, Nov 16, 2022 at 11:57:23AM +1100, Dave Chinner wrote: > The fact that Christoph NAK'd exporting mapping_seek_hole_data() > this time around is just Plain Fucking Annoying. Thank you so much, I love you too. > He didn't say > anything in the last thread about it after I explained why I used > it, so I had assumed it was all OK. Quote from the last thread: "So, the whole scan for delalloc logic seems pretty generic, I think it can an should be lifted to iomap, with xfs_buffered_write_delalloc_punch provided as a callback." > I've already been playing patch golf all morning now to rearrange > all the deck chairs to avoid exporting mapping_seek_hole_data(). > Instead we now have an exported iomap function that wraps > mapping_seek_hole_data, and the wrapper function I added in patch 4 > is now the callback function that is passed 3 layers deep into the > iomap code. > > Hence the xfs_buffered_write_delalloc_punch() function needs to > remain - we can't elide it entire like this patch does - because now > we need a callback function that we can provide to the iomap code so > we avoid coupling internal XFS implementation functions to external > VFS APIs. Which was roughly was the intention all along.
