Clay Harris wrote: > On Tue, Jul 14 2020 at 14:08:26 -0700, Josh Triplett quoth thus: > > The other next step would be to add an IORING_OP_CLOSE_FIXED_FILE > > (separate from the existing CLOSE op) that removes an entry currently in > > the fixed file table and calls fput on it. (With some care, that > > *should* be possible even for an entry that was originally registered > > from a file descriptor.) > > I'm curious why you wouldn't use IOSQE_FIXED_FILE here. I understand > your reasoning for OPEN_FIXED_FILE, but using the flag with the existing > CLOSE OP seems like a perfect fit. To me, this looks like a suboptimal > precedent that would result in defining a new opcode for every request > which could accept either a fixed file or process descriptor. We absolutely could use IORING_OP_CLOSE with IOSQE_FIXED_FILE as the userspace interface. It would take a bit of refactoring to make that work, since unlike other cases of IOSQE_FIXED_FILE we don't just want a struct file in both cases and instead we need the file descriptor (to close it) in the non-fixed-file case, but I agree that that would make sense as the userspace interface.
