> On the other hand, the filesystem writers here are declaring their own > setattr operation. Is it unreasonable for them to take responsibility > for handling this too? We have about half of all the in-tree filesystems declaring ->setattr(), and out of those only two that we know would use this. Others haven't commented, which proably means, they just don't care about this issue. And even if most of them would make use of this feature, a inode flag or filesystem flag for a smooth and backward compatible migration is just so much better than risking to break filesystems. And yes, I'm thinking about in-tree filesystems as well. I'm sure you did a thorough audit of all filesystems, but we are all human and can make mistakes. It is _always_ safer to not change an API which could cause silent breakage. And IMO, that's far more important than the beauty of an interface (and ->setattr() is not beautiful with or without an inode flag). > Another alternative might be to rename notify_change(). I don't really > like gratuitously breaking the API, though, and that function is > referenced in a lot of documentation. Changing it might be confusing... Oh no. I'd like less breakage not more. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
