switch binfmts that use ->read() to that (and to kernel_read()
in several cases in binfmt_flat - sure, it's nommu, but still,
doing ->read() into kmalloc'ed buffer...)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* serialize the call of ->release() on per-pdeo mutex
* don't remove pdeo from per-pde list until we are through with it
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Switch huge if-statement in __proc_file_read() around. This then puts the
single line loop break immediately after the if-statement and allows us to
de-indent the huge comment and make it take fewer lines. The code following
the if-statement then follows naturally from the call to dp->read_proc().
Signed-off-by: David Howells <dhowells@redhat.com>
misc device gets ->private_data pointing to struct miscdevice
on open(), so we can use that to get to per-device structure
instead of relying on file_operations being copied into it.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Remove device_open/close() functions as they don't really do anything and
remove Device_Open as it isn't counted atomically and the value isn't used.
Signed-off-by: David Howells <dhowells@redhat.com>
Kill create_proc_entry() in favour of create_proc_read_entry(), proc_create()
and proc_create_data().
Signed-off-by: David Howells <dhowells@redhat.com>
create_proc_entry() shouldn't be used. Rather proc_create_data() should be
used. The proc_write() function is only used by #if'd out code, so delete it
for now.
Signed-off-by: David Howells <dhowells@redhat.com>
Don't use create_proc_entry() in nubus_proc_subdir(). The files created aren't
given any way to use them, so for the moment use create_proc_read_entry() with
a NULL accessor and generate a compile-time warning.
Signed-off-by: David Howells <dhowells@redhat.com>
Adjust printk in create_proc_mconsole() to reflect it is now using
proc_create() not create_proc_mconsole().
Signed-off-by: David Howells <dhowells@redhat.com>
The only part of proc_dir_entry the code outside of fs/proc
really cares about is PDE(inode)->data. Provide a helper
for that; static inline for now, eventually will be moved
to fs/proc, along with the knowledge of struct proc_dir_entry
layout.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Some of the ->show_info() instances really spew a lot; it's not a problem
wrt correctness (seq_read() will grow buffer and call the sucker again),
but in this case it makes sense to start with a somewhat bigger one -
they often do exceed one page worth of output.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Same as single_open(), but preallocates the buffer of given size.
Doesn't make any sense for sizes up to PAGE_SIZE and doesn't make
sense if output of show() exceeds PAGE_SIZE only rarely - seq_read()
will take care of growing the buffer and redoing show(). If you
_know_ that it will be large, it might make more sense to look into
saner iterator, rather than go with single-shot one. If that's
impossible, single_open_size() might be for you.
Again, don't use that without a good reason; occasionally that's really
the best way to go, but very often there are better solutions.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Al Viro