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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130511210641.GQ25399@ZenIV.linux.org.uk>
Date:	Sat, 11 May 2013 22:06:41 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] next cycle fun: ->release() API change

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/