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

2013-05-12 Thread Al Viro
On Sun, May 12, 2013 at 01:06:16AM +0100, Al Viro wrote: > media_file_operations > v4l2_file_operations > snd_hwdep_ops > sound_info_entry_ops > proto_ops > auth_ops > BTW, a lot of those guys are returning void, but there are some that return > int and I think we ought to review those as well. A

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

2013-05-11 Thread Al Viro
On Sat, May 11, 2013 at 02:12:25PM -0700, Linus Torvalds wrote: > On Sat, May 11, 2013 at 2:06 PM, Al Viro wrote: > > > > Less boilerplate? We used to pass inode to fput() as well, but > > switched to passing file alone... > > .. and that was painful. > > The advantage has to be balanced agains

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

2013-05-11 Thread Linus Torvalds
On Sat, May 11, 2013 at 2:06 PM, Al Viro wrote: > > Less boilerplate? We used to pass inode to fput() as well, but > switched to passing file alone... .. and that was painful. The advantage has to be balanced against the pain it causes. I'm not seeing the advantage here as being worth it. If th

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

2013-05-11 Thread Al Viro
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 > > maj

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

2013-05-11 Thread Linus Torvalds
On Sat, May 11, 2013 at 10:22 AM, Al Viro 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

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

2013-05-11 Thread Al Viro
On Sat, May 11, 2013 at 10:05:05AM -0700, Linus Torvalds wrote: > Ugh. You know what? I'd almost prefer to just do it as a single big > commit, *without* the extra churn of then also renaming things. > Because the renaming will just be painful and result in *more* > problems, and quite frankly, th

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

2013-05-11 Thread Linus Torvalds
On Wed, May 8, 2013 at 10:03 PM, Al Viro wrote: > > OK, so I decided to check just how painful would it be to fix that. > Diff had grown well past anything even remotely reasonable for a single > commit (443 files changed, 814 insertions(+), 1843 deletions(-) for the > last snapshot I've t

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

2013-05-08 Thread Al Viro
This is going to be a major PITA, but surprisingly it seems to be more or less feasible. Background: ->release() method in file_operations has wrong prototype. 0.96a: void (*release)(struct inode *, struct file *) introduced as abstraction for minix_release (same type). Called by