On Thu, Aug 12, 2021 at 08:49:14AM +0200, Christoph Hellwig wrote: > On Wed, Aug 11, 2021 at 12:17:08PM -0700, Darrick J. Wong wrote: > > > iter.c is also my preference, but in the end I don't care too much. > > > > Ok. My plan for this is to change this patch to add the new iter code > > to apply.c, and change patch 24 to remove iomap_apply. I'll add a patch > > on the end to rename apply.c to iter.c, which will avoid breaking the > > history. > > What history? There is no shared code, so no shared history and. The history of the gluecode that enables us to walk a bunch of extent mappings. In the beginning it was the _apply function, but now in our spectre-weary world, you've switched it to a direct loop to reduce the number of indirect calls in the hot path by 30-50%. As you correctly point out, there's no /code/ shared by the two implementations, but Dave and I would like to preserve the continuity from one to the next. > > I'll send the updated patches as replies to this series to avoid > > spamming the list, since I also have a patchset of bugfixes to send out > > and don't want to overwhelm everyone. > > Just as a clear statement: I think this dance is obsfucation and doesn't > help in any way. But if that's what it takes.. I /would/ appreciate it if you'd rvb (or at least ack) patch 31 so I can get the 5.15 iomap changes finalized next week. Pretty please? :) --D