user/sven/linux.git/include/linux/fdtable.h, branch v3.9

kill daemonize()

2012-11-29T02:49:02Z

Signed-off-by: Al Viro

new helper: daemonize_descriptors()

2012-09-27T01:10:00Z

descriptor-related parts of daemonize, done right. As the result we simplify the locking rules for ->files - we hold task_lock in *all* cases when we modify ->files. Signed-off-by: Al Viro

new helper: iterate_fd()

2012-09-27T01:09:59Z

iterates through the opened files in given descriptor table, calling a supplied function; we stop once non-zero is returned. Callback gets struct file *, descriptor number and const void * argument passed to iterator. It is called with files->file_lock held, so it is not allowed to block. tty_io, netprio_cgroup and selinux flush_unauthorized_files() converted to its use. Signed-off-by: Al Viro

make expand_files() and alloc_fd() static

2012-09-27T01:09:58Z

no callers outside of fs/file.c left Signed-off-by: Al Viro

take __{set,clear}_{open_fd,close_on_exec}() into fs/file.c

2012-09-27T01:09:58Z

nobody uses those outside anymore. Signed-off-by: Al Viro

take close-on-exec logics to fs/file.c, clean it up a bit

2012-09-27T01:09:56Z

... and add cond_resched() there, while we are at it. We can get large latencies as is... Signed-off-by: Al Viro

take descriptor-related part of close() to file.c

2012-09-27T01:08:56Z

Signed-off-by: Al Viro

expose a low-level variant of fd_install() for binder

2012-09-27T01:08:55Z

Similar situation to that of __alloc_fd(); do not use unless you really have to. You should not touch any descriptor table other than your own; it's a sure sign of a really bad API design. As with __alloc_fd(), you *must* use a first-class reference to struct files_struct; something obtained by get_files_struct(some task) (let alone direct task->files) will not do. It must be either current->files, or obtained by get_files_struct(current) by the owner of that sucker and given to you. Signed-off-by: Al Viro

move files_struct-related bits from kernel/exit.c to fs/file.c

2012-09-27T01:08:54Z

Signed-off-by: Al Viro

new helper: __alloc_fd()

2012-09-27T01:08:53Z

Essentially, alloc_fd() in a files_struct we own a reference to. Most of the time wanting to use it is a sign of lousy API design (such as android/binder). It's *not* a general-purpose interface; better that than open-coding its guts, but again, playing with other process' descriptor table is a sign of bad design. Signed-off-by: Al Viro