> I deliberately went away from that approach based on Dave's feedback > (similarly with the xfs_itruncate_extents() comment in the subsequent > patch). I used the bool that is used here rather than pass the flag > directly, but it's essentially the same idea in terms of exposing the > function signature change to callers. I haven't had time to catch up on the previous iterations, sorry. > > TBH, I don't much care which of the N possible variants of code > factoring we use here, but I think we're officially bikeshedding once > the feedback starts to go in circles as such. ;) So unless I see some > broader/mutual agreement (or a strong preference from the maintainer) on > a change back to something like the original factoring (perhaps using a > flag instead of a bool), I'm going to assume changing it back will > simply reintroduce the previous feedback and leave this as is. FYI, I really hate trivial rappers that just hide a single argument. There are a few use cases for them, mostly because the API has a lot of pre-existing callers that don't care and it would create too much churn. But creating wrappers for both possible arguments of a bool is just silly. Also in general bools can be ver confusing, especially once we grow more than one in a given prototype. If we already only use it to set a flag deeper down I much, much prefer to expose the flag as it is self-documenting, very much unlike a 'true' or 'false' argument. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
