On Sat, May 11, 2013 at 12:16:22PM -0700, Linus Torvalds wrote: > >> Because renaming really doesn't buy us anything but pain. > > > > Umm... I'd rather go the whole way and get rid of inode argument as well, > > while we are at it. It's completely redundant and it's unused in very large > > majority of the instances. > > So? What's the advantage of removing it? Less boilerplate? We used to pass inode to fput() as well, but switched to passing file alone... Put it that way - if you were adding such method today, would you bother with passing an argument that is unused by most of the instances and can be trivially obtained from the argument we have to pass? Sure, back then you had the opposite situation - all non-empty instances were using inode (and none of them even looked at file), but with the mix we have these days... Hell knows; I agree that if we really try to preserve the interface compatibility here, just switching the return type wins, but since the conversion for every particular driver is trivial anyway... > Also, "->close()" would be *exactly* the wrong name to call this, > since it would be absolutely and utterly misleading. "->release()" is > _not_ about close, and in fact the whole return code is partially due > to people thinking it is. It's "->flush()" that gets called at close > time. Agreed - I'd welcome any alternative suggestions, and yes, I understand your point re "just call it 'release'". -- 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
