On Mon, Apr 27, 2020 at 10:34:35PM +0200, Martijn Coenen wrote: > > Also maybe an explicit direct I/O flag, and maybe > > enough padding with a future proof flags bitmap that we can easily > > extend it for new features if they pop up? > > Sounds good. I'm thinking these flags should be separate from > LO_FLAGS_; even though there is already a LO_FLAGS_DIRECT_IO, as far > as I can tell it can only be used to tell whether it's enabled, not to > actually enable it. And it would just get confusing if we add more > flags later. Maybe something like LO_FD_STATUS_FLAG_DIRECT_IO ? I think reusing LO_FLAGS_DIRECT_IO makes sense to me - we have 32 flags in the existing flags field (at least for loop_info64), so we might as well use the field and the flags. Then we need flags validation in that we don't accept new flags through the old interface, and the new one validates that no unknown flags are passed. E.g. in the LOOP_SET_STATUS / LOOP_SET_STATUS64 handler do: lo->lo_flags &= ~(LO_LEGACY_FLAGS); and then in the main function reject anything not known. And then maybe add something like 64 bytes of padding to the end of the new structure, so that we can use flags to expand to it.
