On 4/3/20 10:57 PM, Josh Triplett wrote: > (Note: numbering this updated version v3, to avoid confusion with Jens' > v2 that built on my v1. Jens, if you like this approach, please feel > free to stack your additional patches from the io_uring-fd-select branch > atop this series. 5.8 material, not intended for the current merge window.) > > This new version has an API to atomically increase the minimum fd and > return the previous minimum, rather than just getting and setting the > minimum; this makes it easier to allocate a range. (A library that might > initialize after the program has already opened other file descriptors may need > to check for existing open fds in the range after reserving it, and > reserve more fds if needed; this can be done entirely in userspace, and > we can't really do anything simpler in the kernel due to limitations on > file-descriptor semantics, so this patch series avoids introducing any > extra complexity in the kernel.) > > This new version also supports a __get_specific_unused_fd_flags call > which accepts the limit for RLIMIT_NOFILE as an argument, analogous to > __get_unused_fd_flags, since io_uring needs that to correctly handle > RLIMIT_NOFILE. > > > Inspired by the X protocol's handling of XIDs, allow userspace to select > the file descriptor opened by a call like openat2, so that it can use > the resulting file descriptor in subsequent system calls without waiting > for the response the initial openat2 syscall. > > The first patch is independent of the other two; it allows reserving > file descriptors below a certain minimum for userspace-selected fd > allocation only. > > The second patch implements userspace-selected fd allocation for > openat2, introducing a new O_SPECIFIC_FD flag and an fd field in struct > open_how. In io_uring, this allows sequences like openat2/read/close > without waiting for the openat2 to complete. Multiple such sequences can > overlap, as long as each uses a distinct file descriptor. > > The third patch adds userspace-selected fd allocation to pipe2 as well. > I did this partly as a demonstration of how simple it is to wire up > O_SPECIFIC_FD support for a new fd-allocating system call, and partly in > the hopes that this may make it more useful to wire up io_uring support > for pipe2 in the future. This looks pretty clean and flexible to me, and it'll work fine for io_uring. Care to post this a bit wider (and CC Al)? -- Jens Axboe