Re: [RFC] next cycle fun: ->release() API change

[Al Viro <viro@ZenIV.linux.org.uk>]

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'".