lkml.org 
[lkml]   [2013]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: pipe_release oops.
From
On Tue, Mar 12, 2013 at 6:06 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> While we are at it, I don't see any reason for having separate file_operations
> for r/o, w/o and r/w cases; the only differences are in EBADF-returning
> ->read() and ->write() (and ->f_mode checks in vfs_read() et.al. take care of
> that) and micro-optimizations in ->release() and ->fasync().
>
> Frankly, I really wonder if we should simply use def_fifo_fops for ->i_fops
> in get_pipe_inode() and let open() via /proc/<pid>/fd/<n> act as it would for
> FIFOs, O_NONBLOCK and all. IOW, how about we simply merge all those
> file_operations in one, folding fifo.c into pipe.c? And to hell with any
> reassignments of ->f_op.
>
> I'm probably missing something subtle here...

Probably not missing anything subtle. I think all of this code is very
old, and related to previous /proc/<pid>/fd/<n> escapades. And the
semantics for those files were in flux some time long long ago (the
whole "dup vs new struct file" issue), it's all just duct-tape, I
think.

Linus


\
 
 \ /
  Last update: 2013-03-12 17:01    [W:0.117 / U:0.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site