Having examined H. Peter Anvin's patches to merge asm/posix_types.h together, I think that we can go further: The FD_SET(), FD_CLR() and FD_ISSET() macros are only used within the kernel itself in relation to the arrays of fd-is-open flags and close-on-exec flags. FD_ZERO() is not used at all within the kernel. Now, the FD_SET() & co. wrappers must be exported to userspace, so they must be kept, but the __FD_SET() & co. implementations behind them on most arches are _not_ so exported. Possibly PowerPC, MN10300 and Xtensa would survive their removal entirely from the userspace API as per Peter's patches. Examining the two remaining usages of struct fd_set, and FD_*() and __FD_*() for the arrays of bits in struct fdtable, it would seem that we could just move to using unsigned long directly rather than fd_set, and using __set_bit(), __clear_bit() and test_bit() upon those. This would also get rid of two abuses of the fd_set struct within this code: (1) Most of the time, the two fd_sets pointed to by struct fdtable are not the length they're supposed to be, and are, in fact, allocated short. This means FD_ZERO() may not be used on them, for example. Basically, in effect, alloc_fdmem() allocates an array of unsigned longs just long enough and then casts it to an fd_set - so why bother with the fd_set at all? (2) Non-core VFS code (such as SELinux) sometimes wants to look through the array of unsigned longs inside the fd_set for the purposes of more efficient iteration over the entire set of open fds - so why not just eliminate the fd_set and go directly with an array of unsigned longs? Furthermore, within the kernel, __FD_SET() and co. are redundant bitops and, in the original implementation, may actually be less efficient. For instance, on x86/x86_64, __set_bit() uses the BTS instruction, but __FD_SET() may well not (depending on the optimiser). I note that Peter's patch does alter this. So my patches do the following: (1) Wrap the normal set/bit/test operations on the open_fds and close_on_exec fd_sets so that the access to them is, for the most part, not open coded. There's still the issue of the things that poke around inside the fd_sets behind the scenes (SELinux for example). (2) Replace the fd_set with an unsigned long array and use __set_bit() and co. instead of FD_SET() and co. It might just be better to replace the uses of FD_SET() and co. with __set_bit() and co. directly, and not bother with wrappers, but the wrappers are more greppable. (3) Delete __FD_SET() and co. from linux/time.h. And are implemented to go on top of Peter's posix_types patchset. David --- David Howells (3): Delete the __FD_*() funcs for operating on fd_set from linux/time.h Replace the fd_sets in struct fdtable with an array of unsigned longs Wrap accesses to the fd_sets in struct fdtable Documentation/filesystems/files.txt | 4 +- arch/powerpc/platforms/cell/spufs/coredump.c | 2 - drivers/staging/android/binder.c | 10 ++--- fs/autofs4/dev-ioctl.c | 2 - fs/exec.c | 8 ++-- fs/fcntl.c | 18 ++++----- fs/file.c | 54 +++++++++++++------------- fs/open.c | 4 +- fs/proc/base.c | 2 - fs/select.c | 2 - include/linux/fdtable.h | 46 ++++++++++++++++------ include/linux/time.h | 22 ----------- kernel/exit.c | 2 - security/selinux/hooks.c | 2 - 14 files changed, 88 insertions(+), 90 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html