> Yes, some filesystems then still get the inode lock in write mode, but > now it's the filesystem itself that wraps its own iterator, rather > than cause pain for the callers. And, btrfs already does this in some cases where it first upgrades from shared to non-shared and then downgrades again before returning in btrfs_real_readdir(). So it's not like this isn't already happening. > > So no more "Do you have an ->iterate() _or_ ->iterate_shared() > function?" and associated "I need to do locking differently" > nastiness. Only odd filesystems that never got the memo on "don't use > .iterate". Ack. It's not pretty but that hasn't stopped us before and it's less ugly than double inode methods which pass exactly the same parameters. I think removing the double methods is good and I see no problem in shaming filesystems that didn't manage to convert properly in the last 7 years. And let's please not get stuck on incoming pinky promises that everyone will have converted before the next 7 years are over. I'd prefer to see the iop wiped and leave the ugliness to the individual filesystems rn.
